Re: [lmi] Distinguish $exec_prefix from $prefix ?

[Vadim Zeitlin]

On Fri, 19 Apr 2019 14:45:08 +0000 Greg Chicares <address@hidden> wrote:

GC> Distinguish $exec_prefix from $prefix

 This does look like a good idea in theory.

GC> In theory at least, $exec_prefix is separate from $prefix:
GC> 
GC> https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
GC> | Generally, $(exec_prefix) is used for directories that contain
GC> | machine-specific files (such as executables and subroutine libraries),
GC> | while $(prefix) is used directly for other directories.
GC> 
GC> https://www.gnu.org/software/autoconf/manual/autoconf.html
GC> | exec_prefix
GC> | The installation prefix for architecture-dependent files.
GC> 
GC> and $exec_prefix needn't be identical to $prefix or even a subdirectory
GC> of $prefix--in theory at least.

 Interesting, I hadn't thought of not making $exec_prefix a subdirectory or
$prefix before -- but you're right, there is no reason it shouldn't work.

GC> Thus, instead of building autotoolized libraries this way:
GC>   --prefix=/opt/lmi/"$host_type"/local
GC>   --exec-prefix="$prefix"
GC> it would seem better to build them this way [option X]:
GC>   --prefix=/opt/lmi/local
GC>   --exec-prefix="$prefix"/"$host_type"
GC> or even this way [option Y]:
GC>   --prefix=/opt/lmi/local
GC>   --exec-prefix=/opt/lmi/"$host_type"/local
GC> 
GC> Attempting to use option Y failed in ways that seemed difficult to fix
GC> (wxWidgets built successfully with either X or Y, but liblzma and
GC> libxml2 didn't; perhaps their maintainers have blithely assumed that
GC> $exec_prefix is a subdirectory of $prefix), so this commit implements
GC> option X.

 I personally prefer the option X anyhow (although I hesitate to explain
why), so unless you feel strongly about the option Y, I'm not going to look
into the reasons of these failures.

GC> And it's almost successful: lmi builds and works correctly
GC> except that lzma support for product files fails the test here:
GC>   https://lists.nongnu.org/archive/html/lmi/2017-08/msg00061.html
GC> That failure is not unanticipated, because libxml2 configuration says
GC>   "checking for LZMA...no"
GC> for option X, both with and without this change:
GC> -  --with-lzma=$(prefix) \
GC> +  --with-lzma=$(exec_prefix) \

 The trouble is that libxml2 configure uses the directory passed to
--with-lzma option in both CFLAGS and LIBS and, clearly, it can't work for
both because the former is for arch-independent headers while the latter is
for arch-dependent libraries.

 A simple workaround would be just set CFLAGS and LIBS explicitly, i.e.
pass "CFLAGS=-I$prefix/include LIBS=-L$exec_prefix/lib" to configure
instead of --with-lzma. I haven't tested it yet, but I think this should
work. It's a bit less clear though.

 An alternative, and generally preferable, workaround would be to use
pkg-config for the library detection. I think we do already install
pkg-config under Cygwin and so we probably just need to set
PKG_CONFIG_PATH=$exec_prefix/lib/pkgconfig to make the automatic detection
work. I didn't test this neither and here I'm not completely sure if this
is enough to make things work because I don't know of liblzma installs its
.pc file under $exec_prefix correctly.

GC> Therefore, although this revision is committed because it's interesting,
GC> apparently it must be reverted because the autotoolization of libraries
GC> in widespread use is incompatible with the autotools vision, and the
GC> only reliable method is '--exec-prefix="$prefix"', which installs
GC> architecture-independent headers to an architecture-dependent directory.

 It's not a huge problem, of course, to have 2 (or even more) copies of the
headers, so maybe it's not worth pursuing this further. But I -- as you, I
suspect -- find it cleaner to separate arch-dependent and arch-independent
files and I don't think it would be that difficult to make this work using
one of the proposals above.

 Should I try to do this and make a patch/PR against odd/multiarch branch?

GC> It is also noteworthy that 'install_msw.sh' had to change, replacing
GC> '/opt/lmi/"$LMI_HOST"/local/bin' with '/opt/lmi/local/"$LMI_HOST"/bin'.
GC> This suggests that it's a defect to compose such paths in multiple
GC> places (and there are other likely defects in the same file, in cygwin-
GC> specific code). Perhaps this means that all the local variables in
GC> 'set_arch.sh' should be exported.

 Speaking about cd1b383b6eb30f96476bd2c5ec50d39edf506a18 contents, I'm more
surprised by the changes to local{bin,lib}dir in GNUmakefile and
set_arch.sh: why have they switched from using $exec_prefix to $prefix? I
think they should be set to $exec_prefix/{bin,lib} respectively.

 As for install_msw.sh change, it might be better to use $exec_prefix/bin
there too, but it's not that important one way or the other, I think.

 Regards,
VZ