Re: [lmi] Dependencies and submodules

[Vadim Zeitlin]

On Thu, 25 Mar 2021 19:43:29 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> But consider what might ideally be done (and may be possible today).
GC> Suppose we use libraries {wx, wxPdf, libxml2, xmlwrapp} "directly" as
GC> you describe above. Then a continuous-integration job could pull all
GC> available library updates nightly, and find upstream issues immediately.

 This is indeed possible to do even today and it would have been helpful to
have this in place to find about the breakage of the GUI test when it
happened, rather than much later. I'll add this to my TODO list, although
not really at the top.

GC> If nothing upstream changes, then the incremental cost is just the
GC> time it takes 'make' to determine that it doesn't have to do anything.
GC> I don't know what that cost is, though maybe you do. If it takes even
GC> ten seconds, then that might actually be meaningfully inconvenient.

 make is pretty slow, so it could take a couple of seconds, but, unless
you're using a really slow machine, definitely not ten. Of course, even an
extra second or two can be annoying.

GC> Probably wx is our most active library. Let's suppose it changes on
GC> most days, and maybe several times a day. Rebuilding wx really is
GC> costly; perhaps it would double our build times. That's inconvenient.
GC> And continuously integrating wx means we'd be subject to any mistake
GC> that any wx developer might make. As a routine nightly test on github,
GC> that might be very worthwhile, but for the lmi rebuilds that I'm doing
GC> many, many times a day, it would not make sense.

 Yes, absolutely.

GC> Maybe the ideal is to use all libraries "directly" as above,

 I'm sorry, I think I might have made another mistake in explaining what I
meant by "directly" in my previous message, so, just to be sure, I'd like
to clarify that this was completely orthogonal to, and didn't imply,
updating the submodule with every upstream commit. All I meant was that
instead of running install_wx.sh to configure, build and install wxWidgets
headers and libraries somewhere else, the main lmi make could

1. Build wx as necessary arranging for the libraries to end up in the same
   directory as the lmi binaries being build.
2. Use -Ithird_party/wx/include when compiling lmi sources.

I.e. "directly" just meant "without passing by an extra installation step".
We could still use the submodules "directly" even if we updated them as
infrequently as we do today, even though it's true that its benefits would
be more apparent if we updated them more often.

GC> but update them infrequently, and only by deliberate intention

 I do agree with this. Automatic tests don't capture everything,
unfortunately, so each update needs manual testing and so can't be done
automatically.

GC>  - For headers: instead of installing them explicitly, we'd just use
GC>    them where they are in the submodules. The only real difference is
GC>    that we'd save the trouble of installing them. But that doesn't
GC>    seem very significant: the code to install headers is small and
GC>    inexpensive to maintain.

 Yes, this is true, but it just seems unnecessary to make all these extra
copies without any real need.

GC>  - For source and binaries: we'd still have to rebuild, infrequently.
GC>    These libraries use autotools, and we're never going to integrate
GC>    them into lmi's makefiles: way too much work, for no real benefit,
GC>    AFAICS.

 Yes, we wouldn't integrate them, the step (1) above would delegate to the
existing wx makefiles. But this would indeed add an extra delay to each and
every lmi build, which may be undesirable, even if the delay is relatively
small (but if we do it for wx, surely we should do it for all the other
libraries too, and then it might not be that small any longer...).

GC> My tentative conclusion is that we should do nothing, as there's
GC> approximately nothing to be gained here. Making lmi's build system
GC> marginally less idiosyncratic in this one respect is no real benefit.

 Yes, I tend to agree. If I started a new project from scratch, I wouldn't
do it like lmi does, but I don't think it's worth changing it.

GC> But now it crystallizes: we should do nothing here, and now that I
GC> understand better, there's no difference between our viewpoints.

 And I agree again.

 Sorry for a rather dull response,
VZ

pgpX59RloomhY.pgp
Description: PGP signature