Re: [lmi] Linux makefiles update

[Greg Chicares]

On 2008-03-14 01:58Z, Vaclav Slavik wrote:
> Greg Chicares wrote:
>> (2) Would it be a bad idea to write this, e.g.,
>>
>>   dist_xrc_DATA = `ls -1 *.xrc *.xpm`
[...]
> now it's XSL files that are broken. So I think we should go ahead
> and replace these two enumerations with the following:
> 
> dist_xrc_DATA = $(shell ls -1 $(srcdir)/*.xrc $(srcdir)/*.xpm)
> dist_xsl_DATA = $(shell ls -1 $(srcdir)/*.xsl)
> 
> ("$(shell ...)" is needed because GNU make won't understand
> backsticks in dependencies list; $(srcdir) is needed for
> out-of-tree builds)

(Incidentally, this:
  http://www.gnu.org/software/automake/manual/html_node/wildcards.html
gives the reason for not using '$(wildcard ...)':
  "it is not portable to other make implementations"
though I think we're right to dismiss that article's other
objections and use 'ls'.)

On 20080315T1457Z I committed almost all of your patch, but I
think we need to defer the 'pkgdatadir' part.

>> (3) Nearby I see this comment:
>>
>> # TODO: we should install them in $(pkgdatadir)/resources or
>> something similar #       (but for this the code in main_wx.cpp
>> must be modified to allow it) xrcdir = $(bindir)
>>
>> and I wonder whether we can resolve that issue. All these files
>> are assumed to reside wherever this 'getopt' argument specifies:
>>
>>         {"data_path" ,REQD_ARG ,0 ,'d' ,0 ,"path to data files"},
>>
>> The path defaults to '.' if it's not specified. That's a
>> convenience for msw end users,

The actual motivating reason for '.' as a default is written just
above the ctor in 'global_settings.cpp':

/// objects of the boost filesystem library's path class are created
/// from these strings, which, if the strings were empty, would trigger
/// exceptions when passed to that library's directory_iterator ctor.

'.' is the minimal string that doesn't violate that precondition.
It's just a happy coincidence that '.' works well for msw users.

>> who keep all files in a single
>> directory, e.g., 'C:\lmi-20080224Z\' for the latest release.
>> If $(xrcdir) is to be used for 'make distrib', then this recipe:
>>
>> $<version.hpp sed -e'/LMI_VERSION/!d'
>> -e's|^.*"\([0-9A-Z]\{8\}\).*$|/lmi-\1Z|'

Although that's what we do for msw distribution, you correctly
point out that it wouldn't be the right 'pkgdatadir' for other
platforms:

> It's used by make install and a reasonable default would be
> $prefix/share/lmi, that's what people expect on Unix.

Okay, I agree that we must honor that expectation.

This patch follows the idiom recommended by autoconf:

> diff -u -u -r1.17 global_settings.cpp
[...]
>      ,regression_testing_        (false)
> +#ifdef LMI_DATADIR
> +    ,data_directory_            (LMI_DATADIR)
> +#else
>      ,data_directory_            (".")
> +#endif
>      ,regression_test_directory_ (".")
>  {}

But the autoconf manual anticipates my philosophical objection:

http://www.gnu.org/software/libtool/manual/autoconf/Defining-Directories.html
| Note that all the previous solutions hard wire the absolute
| name of these directories in the executables, which is not a
| good property.

and I'd like to find another way to achieve the same goal,
especially because there's a practical problem, too. Consider:

'global_settings.hpp'
/// data_directory_: Path to data files.

That's a good and simple idea: it's what autoconf would call
'pkgdatadir'...except when it isn't:

'configurable_settings.hpp'
/// xsl_directory_: Directory where xml and xsl files reside.
/// TODO ?? CALCULATION_SUMMARY Should this be expunged, since these
/// files actually reside in the data directory?

Several member variables in one of those classes are documented
as probably belonging in the other. I'm beginning to think that
'data_directory_' should be in the "configurable" class, which
manages persistent settings in an xml file. If we move it there,
then 'Makefile.am' can just echo something like
    <data_directory>$(pkgdatadir)</data_directory>
to that file. Then autotools and the hand-written makefiles
would both do the same generic thing, and both could have their
behavior customized in the same way:
  make pkgdatadir=/some/custom/directory install
which would affect only the xml configuration file--not the C++
source, because we'd introduce no conditional compilation.

And it turns out that we have other pressing issues with
  global_settings.?pp
  configurable_settings.?pp
that we must address pretty soon anyway, so let's defer this
matter for the moment.