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

[Greg Chicares]

On 2014-10-30 13:28Z, Vadim Zeitlin wrote:
> On Thu, 30 Oct 2014 00:43:28 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> LMI_SO is dll[ex|im]port for msw compilers that need it, but perhaps
> GC> more importantly it's the ELF visibility attribute. I don't know
> GC> whether the latter ever really caught on,
> 
>  This is an easy one: yes, it did. It's universally supported and used by
> all non-trivial C++ shared libraries because it allows to export many fewer
> functions which helps the run-time linker enormously resulting in
> dramatically better load times.

That's good to hear. Today, at least, I'm not personally concerned with
how fast things load on *nix platforms; I just thought it was a nice
idea that could help keep things encapsulated.

> GC> But here we expose first one class, then another...
> GC> 
> GC> The farmer takes a wife
> GC> The wife takes the child
> GC> ...
> GC> The rat takes the cheese
> GC> ...and pretty soon everything's "encapsulated" in a single ocean.
> 
>  I don't think I can agree with this. The encapsulated parts are those
> which are not exported, i.e. those without LMI_SO, and there are still
> quite a few of those. IMHO it's not a problem to export those parts which
> are already used outside of liblmi.dll, it's just a recognition of the fact
> that they are, indeed, used.

I don't understand your disagreement. Everything builds correctly with
LMI_SO; doesn't that prove that the encapsulated parts are not used
outside of 'liblmi.dll'?

> Ideally all the classes and functions which
> could be used outside of this DLL would be marked with LMI_SO, while none
> of the rest would be.

AFAICT, that ideal has been achieved. Are you referring to the changes
in your second patch, which I applied in revision 6030? I would suggest
that the revised code, e.g.:
  cell["GeneralAccountRate"].str()
uses an exported interface which is intended to be used outside the dll,
whereas earlier revisions used a non-exported interface.

> <off-topic linguistic remark>
>  [...] BTW, I am glad to say that I think I've
> finally understood what does yare_input mean, after looking up the word
> "yare" in a dictionary. Until now I kept thinking of it as "yet another
> regularly expressible input" which seemed almost but not quite right.

Classically defined by Katharine Hepburn in "The Philadelphia Story":

  "My, she was yare."
  "Yare? What's that mean?"
  "It means, uh, easy to handle, quick to the helm, fast, bright.
    Everything a boat should be--until she develops dry rot."

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

Patches applied 20141107T0056Z (revision 6029) and 20141107T0122Z
(revision 6030).

As for the mysterious message box, it's apparently due to the
boost::filesystem name-check policy. I don't see it here, so I'm not
sure why you do. Could it be because you're using the ms compiler?
If so, then that would suggest that this function
  void initialize_filesystem()
  {
      fs::path::default_name_check(fs::native);
      fs::initial_path();
  }
hasn't been called. Alternatively, if you see this on *nix, that must
mean that we have mistakenly hardcoded a native msw path somewhere.

Here's a strange coincidence--I rebuilt this way:
  make all build_type=so_test USE_SO_ATTRIBUTES=1
and then built 'cgi_test', which spat this on my screen:
  Assertion 'DB_FIRST <= key_ && key_ < DB_LAST' failed.
  [file /lmi/src/lmi/dbvalue.cpp, line 329]
I deleted the build directory and rebuilt it the same way from scratch,
and the problem is no longer reproducible. This is disquieting enough
to record it here in case it ever happens again, but I'm not going to
worry any more about it now.