Re: [lmi] Special build types, e.g. gcov

[Vadim Zeitlin]

On Fri, 07 Nov 2014 02:12:56 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-10-30 13:28Z, Vadim Zeitlin wrote:
GC> > On Thu, 30 Oct 2014 00:43:28 +0000 Greg Chicares <address@hidden> wrote:
...
GC> > GC> But here we expose first one class, then another...
GC> > GC> 
GC> > GC> The farmer takes a wife
GC> > GC> The wife takes the child
GC> > GC> ...
GC> > GC> The rat takes the cheese
GC> > GC> ...and pretty soon everything's "encapsulated" in a single ocean.
GC> > 
GC> >  I don't think I can agree with this.
...
GC> I don't understand your disagreement. Everything builds correctly with
GC> LMI_SO; doesn't that prove that the encapsulated parts are not used
GC> outside of 'liblmi.dll'?

 I was disagreeing with the perceived idea that using LMI_SO was useless
because it was "contagious" and exporting one thing led to exporting
another one and so on. Rereading the previous message, I'm not sure you
actually meant that any more, but in any case I just wanted to say that
visibility declarations could be useful even if a lot of things were
visible -- because at the very least they tell that those that are not
should not be used from the outside of the module and so work just as
"private" access control keyword in C++. Except that, unfortunately,
visibility control only works at link time, only when using shared
libraries and only really under Unix.

GC> > Ideally all the classes and functions which could be used outside of
GC> > this DLL would be marked with LMI_SO, while none of the rest would
GC> > be.
GC> 
GC> AFAICT, that ideal has been achieved. Are you referring to the changes
GC> in your second patch, which I applied in revision 6030? I would suggest
GC> that the revised code, e.g.:
GC>   cell["GeneralAccountRate"].str()
GC> uses an exported interface which is intended to be used outside the dll,
GC> whereas earlier revisions used a non-exported interface.

 Yes, my problem was that I (mistakenly) wrote code using non-visible
classes. I didn't know that I could already rely on LMI_SO being used
correctly everywhere and so indicating which classes could and could not be
used. It's very good to know that I can.

 As an aside, I think it's even more important than usual in the LMI case
because it uses a flat file structure which, while convenient in other
ways, doesn't give any hints about which files are "public" (define
exported API) and which ones are not. E.g. with wxWidgets you have public
headers in include/wx and private ones in include/wx/private and the name
of the directory strongly hints at the intended usage. But with LMI, LMI_SO
is really the only thing you can rely on to tell you this.

GC> >  To summarize, with the attached patches the tests build in both normal
GC> > ("ship") and "so_test" builds and still pass in the former. They do not
GC> > pass in the latter, however, with the following mysterious message box
GC> > given on startup:
GC> [...]
GC> >   boost::filesystem::path: invalid name "C:" in path: 
"C:/opt/lmi/data/new-16.png"
GC> > 
GC> > (the file in question does exist BTW). This is not specific to the tests,
GC> > the main LMI executable itself, built with USE_SO_ATTRIBUTES=1, gives
GC> > exactly the same error and refuses to start, so I guess it's worth looking
GC> > into this and I'll do it later. But the patches here should still be
GC> > applied IMHO, as they at least make the test build -- and also because 
they
GC> > make the test code simpler and more clear.
...
GC> As for the mysterious message box, it's apparently due to the
GC> boost::filesystem name-check policy. I don't see it here, so I'm not
GC> sure why you do. Could it be because you're using the ms compiler?

 No, it only appears when using official LMI build system, albeit under
Windows 7. I do think it's somehow related to initialize_filesystem() but I
don't see how exactly yet... I'll debug this after finally submitting my
test cleanup patches (thanks for committing my preliminary patch!).

VZ