Re: [lmi] Data directory and libraries to preload

[Greg Chicares]

On 2016-05-31 20:41, Vadim Zeitlin wrote:
> 
>  The recent mention of the circular dependency on data directory reminded
> me about a related problem described by the following comment in the
> configuration_filepath() function in configurable_settings.cpp (with some
> extra context for clarity):
> 
>     std::string filename = LMI_INSTALL_PREFIX "/etc/opt/lmi/"
>                             + configuration_filename();
>     if(0 != access(filename.c_str(), R_OK))
>         {
>         // TODO ?? At this point, AddDataDir() refers to the directory
>         // where the wx binary resides. A configurable_settings object
>         // apparently exists before ProcessCommandLine() is called.
>         filename = AddDataDir(configuration_filename());

Yes, I was just rereading that a day or two ago.

>  The comment is correct, this code is called before the command line is
> parsed and so even if the --data_path option is specified, it is not taken
> into account here and configurable_settings.xml must exist either in the
> default location ("$prefix/etc/opt/lmi") or in the executable directory.
> I don't know if it's a real problem in practice, I guess it isn't as normal
> lmi users do always have the global configuration file, but it's still
> somewhat annoying.

It's not a practical problem for end users--IIRC, they always have
'configurable_settings.xml' in the executable directory. But it's a
nuisance to me, and besides, it's just unclean.

>  And there is a simple way to avoid this

Wow...I'm all ears...

> because the reason for this
> happening is the call to MswDllPreloader::PreloadDesignatedDlls() early
> during the startup process.

Really? I don't perceive the connection. Oh, wait...the list of dlls
to preload is in 'configurable_settings.xml'.

> I don't think it's really necessary to preload
> these DLLs so early, surely we could do this in Skeleton::OnInit() after
> parsing the command line options, couldn't we?

Sounds good. The whole point of preloading DLLs is to prevent them
from blithely smashing the FP control word. In theory at least,
parsing the command line doesn't involve floating point.

Since you've figured this out, would you mind proposing a patch?