BIND 10 trac558, updated. 1e3a2586abe597550611cca5697916f311ffd2a9 [trac558] Changes to comments in the message compiler

[BIND 10 source code commits]

The branch, trac558 has been updated
       via  1e3a2586abe597550611cca5697916f311ffd2a9 (commit)
      from  f0324078a088345812c5397317b66445b02f82be (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 1e3a2586abe597550611cca5697916f311ffd2a9
Author: Stephen Morris <stephen at isc.org>
Date:   Thu Feb 17 10:20:51 2011 +0000

    [trac558] Changes to comments in the message compiler

-----------------------------------------------------------------------

Summary of changes:
 src/lib/log/compiler/message.cc |   34 ++++++++++++++++++++++++++++------
 1 files changed, 28 insertions(+), 6 deletions(-)

-----------------------------------------------------------------------
diff --git a/src/lib/log/compiler/message.cc b/src/lib/log/compiler/message.cc
index 915c99a..41f6149 100644
--- a/src/lib/log/compiler/message.cc
+++ b/src/lib/log/compiler/message.cc
@@ -55,13 +55,13 @@ static const char* VERSION = "1.0-0";
 /// \b Invocation<BR>
 /// The program is invoked with the command:
 ///
-/// <tt>message [-p] \<message-file\></tt>
+/// <tt>message [-v | -h | \<message-file\>]</tt>
 ///
 /// It reads the message file and writes out two files of the same name but with
 /// extensions of .h and .cc.
 ///
-/// If \c -p is specified, the C++ files are not written; instead a Python file
-/// of the same name (but with the file extension .py) is written.
+/// \-v causes it to print the version number and exit. \-h prints a help
+/// message (and exits).
 
 
 /// \brief Print Version
@@ -242,7 +242,10 @@ writeClosingNamespace(ostream& output, const vector<string>& ns) {
 
 /// \brief Write Header File
 ///
-/// Writes the C++ header file containing the symbol definitions.
+/// Writes the C++ header file containing the symbol definitions.  These are
+/// "extern" references to definitions in the .cc file.  As such, they should
+/// take up no space in the module in which they are included, and redundant
+/// references should be removed by the compiler.
 ///
 /// \param file Name of the message file.  The header file is written to a
 /// file of the same name but with a .h suffix.
@@ -326,8 +329,27 @@ replaceNonAlphaNum(char c) {
 /// \brief Write Program File
 ///
 /// Writes the C++ source code file.  This defines the text of the message
-/// symbols, as well as the initializer object that sets the entries in
-/// the global dictionary.
+/// symbols, as well as the initializer object that sets the entries in the
+/// global dictionary.
+///
+/// The construction of the initializer object loads the dictionary with the
+/// message text.  However, nothing actually references it.  If the initializer
+/// were in a file by itself, the lack of things referencing it would cause the
+/// linker to ignore it when pulling modules out of the logging library in a
+/// static link.  By including it in the file with the symbol definitions, the
+/// module will get included in the link process to resolve the symbol
+/// definitions, and so the initializer object will be included in the final
+/// image. (Note that there are no such problems when the logging library is
+/// built as a dynamically-linked library: the whole library - including the
+/// initializer module - gets mapped into address space when the library is
+/// loaded, after which all the initializing code (including the constructors
+/// of objects declared outside functions) gets run.)
+///
+/// There _may_ be a problem when we come to port this to Windows.  Microsoft
+/// Visual Studio contains a "Whole Program Optimisation" option, where the
+/// optimisation is done at link-time, not compiler-time.  In this it _may_
+/// decide to remove the initializer object because of a lack of references
+/// to it.  But until BIND-10 is ported to Windows, we won't know.
 
 void
 writeProgramFile(const string& file, const string& prefix,