Re: [lmi] Directory structure for multiple-architecture builds

[Greg Chicares]

On 2017-05-23 16:48, Vadim Zeitlin wrote:
> On Tue, 23 May 2017 16:42:27 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2017-05-23 14:29, Vadim Zeitlin wrote:
> GC> [...]
> GC> >  I've just realized that I don't actually know how is the end user
> GC> > distribution created. Does it use the same structure with "bin"
> GC> > subdirectory? This would be somewhat unusual (although not exactly 
> unique)
> GC> > for a MSW application...
> GC> 
> GC> We copy everything into a single flat directory
> 
>  But then the prefix used for the parent directory doesn't matter at all
> and it seems that we can use the canonical string (whether it's based on
> uname or host triplet) without any danger, so why did you worry about this
> in the previous message where you wrote "it might make a lot of sense to
> use an empty string for the triplet distributed to end users"?

For a couple of decades now we've had the same directory structure,
which is automatically created by 'install_msw.sh' I guess. Any
change might create inconvenience for Kim: actually, we have several
different end-user distributions (with different assortments of
proprietary data files and custom XRC files), and IIRC some shell
or DOS scripts (outside version control) automate this...and they
might hard-code the expected directory names.

However, I now suspect that this issue wouldn't arise if I modify
the makefiles carefully enough. In autoconf terms, $prefix is the
same for all builds--only $exec_prefix differs anyway--and notionally
they only indicate where software is installed. For makefiles that
build libraries, that matters greatly--we want 64-bit libxml2 to be
installed in a 64-bit directory--but for lmi itself, $prefix is just
where the files to be distributed are placed.

And that really does seem to work. I built lmi for 64-bit msw with
this command (and many nasty makefile hacks, and a couple of local
source changes):

make $coefficiency build_type=msw64 exec_prefix=/opt/lmi/x86_64-w64-mingw32 
--output-sync=recurse install check_physical_closure

...yielding...

/opt/lmi/x86_64-w64-mingw32/bin[0]$file ./lmi_wx_shared.exe 
./lmi_wx_shared.exe: PE32+ executable (GUI) x86-64, for MS Windows

...and I can run it from that nondefault install directory:

/opt/lmi/x86_64-w64-mingw32/bin[0]$WINEPATH='Z:\\opt\\lmi\\x86_64-w64-mingw32\\local\\bin;Z:\\opt\\lmi\\x86_64-w64-mingw32\\local\\lib'
 wine ./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data

...and everything works. I had built the libraries with an overriding
exec_prefix:

make $coefficiency exec_prefix=/opt/lmi/x86_64-w64-mingw32/local 
host_type=x86_64-w64-mingw32 --output-sync=recurse -f 
install_libxml2_libxslt.make >../log 2>&1

make $coefficiency exec_prefix=/opt/lmi/x86_64-w64-mingw32/local 
host_type=x86_64-w64-mingw32 --output-sync=recurse -f install_wx.make >../log 
2>&1

make $coefficiency exec_prefix=/opt/lmi/x86_64-w64-mingw32/local 
host_type=x86_64-w64-mingw32 --output-sync=recurse -f install_wxpdfdoc.make 
>../log 2>&1

which specifies where the library dependencies should reside:
  exec_prefix=/opt/lmi/x86_64-w64-mingw32/local
but for lmi I believe I could have used
  exec_prefix=/opt/lmi/x86_64-w64-mingw32
to find those libraries, and then set $prefix to any /foo/bar
and 'make install' would have copied the libraries
  from $exec_prefix
   to  foo/bar

At least I think so. It's hard to be sure right now, because of all the
kludges.