Re: Python recompile

In comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 6 Mar 2025 19:21:45 -0000 (UTC), Waldek Hebisch wrote:
 

Per platform Makefile-s do not scale when one wants to support multiple
system and multiple configurations (there is exponential growth of
possible combinations).  And even of single configuration for supposedly
single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files where x
represented one Linux flavour.  Yet regularly somebody would come and
say: "build fails on my Linux x.y.z".  If enough information was
provided new Makefile was added, or possibly some similar Makefile was
modified to cover more cases.

 
Can you offer more details on the project in question? I ask because
there are things that can be done in GNU Makefiles to deal more
dynamically with environmental differences in some simpler cases,
without resorting to a full-on meta-build system like Autotools or
CMake, and perhaps the maintainers of this project aren’t aware of
that.

I guess that one could do configure-like processing inside a
Makefile generating next stage Makefile.  Autoconf offers
ready-to-use functionalty, like a bunch of sanity checks
or check for X libraries.  There are several subdirectories
each containing its own Makefile, propagating info via substitution
+ fixed makefile fragments looks esier than Makfile includes
+ conditionals that would be required in make-only solution.

If you look at scale, there is something like 2000 source
file in various languages (including about 50000 wc lines
of C).  About 450000 wc lines total, including tests and
documentation (but documentation requires rather involved
build process).  About 140 MB generated files.

Some currently suported features:
- using onf of 5 different non-C compilers, each having diferent
  extentions for compiled files and needing different way of
  creating executable
- matching linking options (shared versus static) and needed
  libraries to used compiler
- blacklisting buggy compiler versions
- optionally including/excluding part of functionality
- optinally using machine independent pre-build files
  (saves compile time for users building from source)

All this requires some code.  It is possible that the work
could be done with less code.  However, history suggest
conservative approach.  Shortening the whole story, this
is largish formerly propritary program that was released
as open source.  First 6 years of open source developement
was mainly spend on build issues.  Nontrivial part on
build system, parts on improving portablity of code,
changing tools, etc.  Current autoconf based build system
probably represent about 1 man year of developement effort.
During last 15 years build system worked requiring small
maintanence effort.  History indicates that changing build
system at least requires some non-trivial effort.  And
there is ample opportunity for troubles.  So simply,
why spend effort on replacing something that works?

Let me mention due to disagreemnts (including build system,
but not only) project forked.  There is or maybe was (in last
few years it made no release) fork which does not use autoconf
and depends on multiple configuration files.  It offered
less flexibility and still regularly had build failures
due to changing Linux configurations.

--
                              Waldek Hebisch