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

[Greg Chicares]

On 2019-04-20 12:28, Vadim Zeitlin wrote:
> On Fri, 19 Apr 2019 14:45:08 +0000 Greg Chicares <address@hidden> wrote:
[...]
> 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

We both prefer X, so we won't pursue Y.

> 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.

I haven't tested it either, but it sounds like it should work.

>  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

Yes, we do, for all build architectures:

$grep pkg-config install_cygwin.bat README.schroot
install_cygwin.bat:   
"autoconf,automake,bsdtar,dos2unix,doxygen,gdb,git,libtool,make,openssh,patch,pkg-config,rsync,unzip,wget,zip,zsh"
README.schroot: pkg-config git cvs zsh bzip2 unzip sudo wine default-jre jing 
trang \

> 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.

It seems to do much the same as many other autotoolized libraries--for
example, I see the following for 32-bit msw (with neither X nor Y above):

/opt/lmi/i686-w64-mingw32/local/lib/pkgconfig/libexslt.pc
/opt/lmi/i686-w64-mingw32/local/lib/pkgconfig/liblzma.pc
/opt/lmi/i686-w64-mingw32/local/lib/pkgconfig/libxml-2.0.pc
/opt/lmi/i686-w64-mingw32/local/lib/pkgconfig/libxslt.pc
/opt/lmi/i686-w64-mingw32/local/lib/pkgconfig/wxpdfdoc.pc

> 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.

Building for two architectures, by running the same do-everything script once
for each, would write the headers twice anyway. And refactoring the scripts
into one step that installs invariant files like headers, and another step
for architecture-dependent parts, sounds like a lot of work for little
practical gain.

Brute force certainly is tasteless, but it does work. I think we should put
this idea aside, at least for now.

> 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.

Quoting the relevant part of that revision:

[GNUmakefile]
 # These directories are outside the scope of the GNU Coding Standards.
 # Therefore, their names may contain '_' for distinction and clarity.
-localbindir     := $(exec_prefix)/local/bin
-locallibdir     := $(exec_prefix)/local/lib
-localincludedir := $(exec_prefix)/local/include
+localbindir     := $(prefix)/local/$(LMI_HOST)/bin
+locallibdir     := $(prefix)/local/$(LMI_HOST)/lib
+localincludedir := $(prefix)/local/include

let me first point out that these assignments work correctly, so they
flow from the changes in the scripts and makefiles for autotoolized
libraries. But $prefix and $exec_prefix differ: in the libraries they're
  prefix        := /opt/lmi/local
  exec_prefix   := $(prefix)/$(host_type)
while in 'GNUmakefile' they're
  prefix        := /opt/lmi
  exec_prefix   := $(prefix)/$(LMI_HOST)

IOW, they're written this way in order to effect this change:
  - /opt/lmi/"$LMI_HOST"/local/{bin,lib}
  + /opt/lmi/local/"$LMI_HOST"/{bin,lib}
and
  - /opt/lmi/"$LMI_HOST"/local/include
  + /opt/lmi/local/include

Curiously, it seems that applying option X for building the libraries
produced a change in lmi that looks like option Y.

>  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.

In that file, only one hunk changed, but the affected code has been
removed as unnecessary.