Re: [lmi] Question about using fardels

[Vadim Zeitlin]

On Thu, 24 Sep 2020 23:26:55 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> I guess the usual autotools idiom is
GC>   ./configure
GC>   make && make install
GC> For lmi, it could be seen as
GC>   ./install_msw.sh
GC>   make install
GC> Of course, 'install_msw.sh' isn't much like 'configure',
GC> but both ways have an initial prerequisite step.

 The problem is indeed not so much the presence of two steps, as the fact
that install_msw.sh is nothing like configure. In particular, it already
does "make install" internally, so there is no separation between it and
make, unlike in configure+make case. This is, INMSHO, a weakness of this
system and I think it would be much more clear and reusable if it could be
separated in 2 distinct parts, the first one setting up the requirements
and the second one actually building/testing/installing.

GC> In an autotools world, where would the code that sets up these
GC> prerequisite files reside? Perhaps we can figure out a parallel
GC> lmi locus and move (or at least duplicate) that code there.

 Configure doesn't do anything like this, it just checks that requirements
are satisfied, but doesn't install them. So you could say that
traditionally this part resides in the project README file explaining what
is needed to build it. It's also common to have some script doing this,
which needs to be run once, before building. And nowadays this script can
be either explicitly or implicitly used by the CI configuration file, which
is present in most of the new projects.

 So IMHO there really should be install_lmi_prereq.sh script, doing just
what its name says, i.e. preparing the system so that you could run "make"
on it successfully. And then install_msw.sh would first call it, then
build, and then run any post-build checks.


 However this still wouldn't address the problems discussed in this thread.
OTOH we don't actually need any drastic changes to solve them. It would be
enough to simply move the creation of /opt/lmi/data/*.png and configurable
settings file into the makefile itself. This would make it more
self-contained, as currently it contains at least one target ("fardel")
which relies on these files existing, but never creates them, which just
seems wrong. Why not have the default copies of these files in Git instead
of creating them dynamically in install_msw.sh? Of course, the script could
still overwrite the logos with the proprietary graphics if they exist in
the specified directory, but at least things would work out of the box by
default. Of course, I might be missing something because currently we do it
the other way round, i.e. create configurable_settings.xml in the source
directory from the file in the data directory, which doesn't make much
sense to me...

 I'd also refactor expiry and related files (validated.md5 and passkey)
creation to have a single target in the makefile for doing it instead of
doing it in install_msw.sh and in fardel_date_script.


 But, not to get lost in the details, I'd like to repeat that my main goal
is to just be able to run some script once, without building anything, and
then run "make" to build lmi (or "make something-else" to build other
things) multiple times without rerunning this script again. And if both
this script and make could use some variable instead of the hardcoded
/opt/lmi everywhere, it would be perfect and enough for me to drop
configure and Makefile.am entirely. I.e. ideally I just want to be able to
run "make install prefix=$HOME/tmp/lmi".


GC> >  BTW, I'm thinking of making the automated CI builds on GitHub produce
GC> > fardel as their "artefact" on output. This would be convenient for me, but
GC> > perhaps it could be useful to have fardels automatically built for each 
new
GC> > commit for you as well?
GC> 
GC> We distribute only binaries generated on equipment controlled
GC> by Corporate IT, which provides some kind of guarantees that
GC> are seen as important. But maybe binaries built on a site
GC> controlled by ms would be acceptable to the overseers, though
GC> facsimiles of Soviet postage stamps could make them worry
GC> about Яussian h4X0rs.

 These binaries definitely wouldn't be usable as "official" ones, but I
thought they could be useful for you to easily test our changes (including
those done on some branch not yet merged in master, which would provide a
simple way to test it before merging).

 Regards,
VZ

pgpEu_NljgmVo.pgp
Description: PGP signature