Re: [lmi] Creating an lmi schroot from scratch

[Vadim Zeitlin]

On Mon, 20 Jul 2020 22:29:09 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Starting from primordial chaos is the use case that motivates these scripts.

 Oh, I've realized that it might not have been clear that I didn't at all
mean to criticize the goal of these scripts, it makes perfect sense in the
context in which you use them, I just hadn't realized before that there was
really no useful intersection between them and what I want to do.

GC> AIUI, you were going to try running these scripts in a redhat or centos
GC> (version 7) VM only.

 Yes, sorry, I've changed the goal posts. I wanted to have a way of quickly
testing the USE_SO_ATTRIBUTES=1 problem, so I've decided that I really had
to set up a Debian Sid chroot where I could build lmi using official
makefiles (because I couldn't reproduce the problem without using them, for
the still unknown reason).

GC> apt-get --assume-yes install wget g++-mingw-w64 automake libtool make \
GC>  pkg-config git cvs zsh bzip2 unzip sudo wine default-jre jing trang \
GC>  g++-multilib libxml2-utils libxslt1-dev vim-gtk vim-doc shellcheck \
GC>  bc libarchive-tools xsltproc rsync curl bsdmainutils \
GC> 
GC> which reports:
GC> 
GC>   The following additional packages will be installed:
GC>   ...
GC>   Selecting previously unselected package patch.
GC> 
GC> and
GC>   apt-cache rdepends --installed patch
GC> suggests that it's required by 'git', but the 'git' package seems
GC> only to recommend it.
GC> 
GC> I can demonstrate that 'patch' is installed, but I can't prove that it
GC> must be, so I'll just add it to the 'apt-get' command above.

 Ah, I see why this hasn't worked for me: I completely forgot that I had
APT::Install-Recommends="false" in this chroot, sorry.

GC> AIUI, /{etc,var,srv,opt} are unixisms, unheard of with msw, but explicitly
GC> allowed by the FHS.

 Yes, the directories are Unixisms, of course, but the use of them for
building (not installing) the program, is quite un-Unixy.

GC> Where in a standard unix hierarchy could you install lmi without using
GC> 'sudo mkdir' (or equivalent) at all? Only in your home directory?

 There is a big difference, that I probably should have made more explicit,
between building software and installing it. For me building absolutely
shouldn't require any special rights, while installing might require them,
although ideally it would be also install into any location to which the
current user has write access without using them.

GC> >  To try making this post at least somewhat constructive, I think it would
GC> > be nice to factor the post-build part of install_msw.sh out of it, e.g.
GC> > maybe have a separate post_install.sh or a "configure_settings" target in
GC> > the main makefile, that would create expiry, validated.md5 and passkey 
files
GC> > as well as configurable_settings.xml itself. And if we could make 
locations
GC> > of these files configurable/overridable via environment/make variables, it
GC> > would be even more convenient.
GC> > 
GC> >  Would it be useful to try to propose patches doing this?
GC> 
GC> What's your endgame?

 I don't really have an endgame, but I have a list of wishes the most
important of which, in the order of importance, are:

1. Be able to build lmi completely inside the given directory. I don't like
   build systems spreading their files in random locations on my system and
   lmi is really unique in this respect. Ideally I'd like to specify the
   location of the build directory myself (e.g. to put it on a faster disk,
   maybe), but by default it really should be a subdirectory of either the
   source or the current directory and not some completely different
   location.

2. Be able to specify the versions of various libraries to use. Of course,
   the most important one for me is wxWidgets, but it could be useful for
   the other ones too. There might be some way to cajole the current build
   system into doing this, but I'd like it to be simple and standard and
   just use WX_CONFIG environment/make variable, defaulting to wx-config.

3. Be able to install lmi under a non-default location, e.g. $HOME/tmp,
   without superuser rights and successfully run it, and the tests, from
   there. Or, alternatively, be able to run it (and the tests) without
   installation, but this risks being even more difficult.

4. Have more granular build process. It's possible, but not really obvious,
   to compile a single file or (re)build a single library right now, but
   I'd like this to be simpler to do because I often do this, e.g. when
   checking a fix to a particular warning I'd like to do "make -B file.o",
   but this doesn't work at all as expected right now.

 There are more of them, but I think I've listed the ones which are the
most important. And, of course, I realize that implementing all of them
would be time-consuming and complicated and maybe not even desirable from
your point of view. So I'll take whichever subset of this that would be
on offer...

 Of course, one of the reasons I'm so relaxed about this is that I hardly
ever use lmi official makefiles, as I mostly build it using MSVS project
files or using autotools-based makefiles under Unix. The problem is that
autotools are not completely identical to the official makefiles because
they use slightly different options. If I could find a way to ensure that
they use exactly the same compiler and linker options, it would solve all
my problems too, but I don't think this is easily possible, unfortunately.

 Regards,
VZ

pgpFbBUJmHrGu.pgp
Description: PGP signature