Re: [lmi] Forcing linking of the library modules (again)

[Greg Chicares]

On 2014-10-04 22:20Z, Vadim Zeitlin wrote:
> On Sat, 04 Oct 2014 21:56:09 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2014-10-04 14:52Z, Vadim Zeitlin wrote:
> GC> > On Sat, 04 Oct 2014 13:20:57 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> I'm puzzled. I think I preserved the original's substance faithfully, 
> but...
> GC> 
> GC> >  But I'd like to notice that there is a small problem with the new
> GC> > LMI_FORCE_LINKING_{IN,EX}_SITU() macros: they are inconsistent in their
> GC> > handling of the subsequent semicolon as the former requires it, while 
> the
> GC> > latter does not.

I think we went astray here. We were discussing the original commit:
  
http://svn.savannah.nongnu.org/viewvc/lmi/trunk/force_linking.hpp?annotate=5957&root=lmi
Wouldn't it be correct to say instead that neither macro required
a semicolon?

> GC> > I would prefer if the latter one required the semicolon as
> GC> > well, i.e. remove the trailing semicolon from the line 61 of
> GC> > force_linking.hpp

With this and subsequent changes, compiling HEAD as of 20141006T1728Z gives:

/lmi/src/lmi/file_command_wx.cpp:41: error: extra `;'
/lmi/src/lmi/system_command_wx.cpp:43: error: extra `;'
/lmi/src/lmi/progress_meter_wx.cpp:40: error: extra `;'

Therefore, I'm reverting the removal of the semicolon in
'force_linking.hpp', and removing the semicolons where
those macros are used.

> GC> 
> GC> Isn't that the same as the trailing semicolon on line 28 here?
> GC> 
> GC>   
> http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/include/wx/link.h?view=annotate
> GC> 28                        } wx link dummy var##module_name;
> GC> 
> GC> Or are you advocating a change to <wx/link.h> as well, for the
> GC> following reason?
> GC> 
> GC> > , as not terminating the macro definition with a semicolon
> GC> > is the common rule
> 
>  Sorry, I have indeed managed to notice the speck in your code but not the
> log in our own version. I must have used the wx macros completely
> automatically, without thinking about this issue at all, while reviewing
> your changes triggered my subconscious C++ critical feeling...
> 
>  Unfortunately it's too late to change wxFORCE_LINK_XXX() macros as they
> are certainly used outside wxWidgets and we don't want to break existing
> code for such relatively unimportant issue.

It seems to me that Vaclav had it right all along.