Make{1,2,3} & Re: gnucap-models

On Sun, Apr 17, 2022 at 01:19:47AM -0400, al davis wrote:
> On Wed, 13 Apr 2022 18:11:56 +0200
> Felix Salfelder <[email protected]> wrote:
> > Please consider the install branch with your next push. The DESTDIR
> > variable facilitates the creation of binary packages from staged
> > installations.
> > 
> > $ make install DESTDIR=/tmp/stage/
> > $ cd /tmp/stage
> > $ tar -cjf ../gnucap-models.tbz2 *
> > 
> > ... Similar in gnucap/Make3.
> 
> 
> gnucap/Make3 already has that patch.
> 
> Other plugins should use Make3 rather than doing it again and again, a
> little different each time.
> 
> The build system is overdue for a consolidation.

I agree. Some normalisation can't hurt. Here are some comments & ideas.

> Make1: the part specific to this directory.
> Make2: local configuration, either stored or generated by configure.
> Make3: list of targets, etc.  Always the same.  Boiler Plate.

Perhaps plugins/extensions should just provide one MakeList (aka Make1)
per directory. Some (replaceable) program, e.g. gnucap-make could take
care of it, and deal with configure and Make{2,3} some way or another.

gnucap/apps is built before Make3 (gnucap-make, gnucap-conf etc.) is
installed. gnucap-models will be built afterwards. Still, they should
follow the same logic. In the long run, all plugins could be built after
installation of a core package. Are we there yet?

gnucap-make could be a shell script, or an extended (and executable)
version of Make3. Executables are nice, because they are in $PATH,
plain makefiles must be located some other way.

c_attach could run gnucap-make (in the far future?), if desired.

Reading MakeList does not require Make. Running configure will require a
POSIX shell, and Make will be needed to interpret Make2. Is this
portable, and can we do better? I.e. gnucap-models does not actually
require configure. How do others?

cheers
felix