Re: [bug #66583] [PATCH] allow building groff without makeinfo

[Alejandro Colomar]

Hi onf,

On Tue, Dec 31, 2024 at 01:18:50PM -0500, anonymous wrote:
> Follow-up Comment #50, bug #66583 (group groff):
> 
> [comment #44 comment #44:]
> > On Tue, Dec 31, 2024 at 07:24:03AM -0500, G. Branden Robinson wrote:
> >> I trust you realize that you and onf are arguing diametrically opposed
> >> objectives here.  He _absolutely_ wants to drive target selection from
> >> the "./configure" script.  Or did.  The plethora of new make(1) target
> >> names he's proposed, he might regard as a complete replacement for that
> >> approach.
> > 
> > I do.
> 
> I would like to correct this.
> 
> I don't want to drive target selection from ./configure, let alone
> "absolutely".
> The reason why my past patches have implemented it this way is that the
> automake
> way of doing things is defining weird make macros that get converted into
> targets
> and added as dependencies to all, and it took me a bit too long to realize
> it's
> possible even with this strange approach to do it the traditional make way.
> (To be honest, it wasn't until Alex's comments that I looked more into it and
> realized it's possible. Feel free to consider me slow.)

I suspected it was due to autotools being crap, rather than you wanting
that on purpose.  I don't mean to say you want that.  Rather that your
current solution involves that.  Please don't take offense from my
words.

I myself haven't written a solution, because I don't know how to solve
this, other than completely scraping the build system, and writing some
GNUMakefile's from scratch.  So, thanks a lot for your attempts!  Slow
is faster than not doing it at all.  :)

> 
> "The plethora of new make(1) target names [I've] proposed" I regard as the
> idiomatic make way to allow building only the binaries, or only the docs.
> If anyone disagrees, I would like to hear your objections; so far I have not
> heard any opinions regarding this proposed approach.
> 
> As for Alex's suspicion of a recursive build and Branden's objections,
> just look into the generated Makefile [re-arranged for clarity]:

[...]

> To sum it up: `make all` does what would be considered a recursive build:
> it runs `$(MAKE) $(AM_MAKEFLAGS) all-recursive`. As far as I can tell, the
> AM_MAKEFLAGS macro is not defined anywhere, so this make does not inherit
> flags the user called make with. This means that what Alex is experiencing
> is this: he runs `make -k [all]`, which runs `make all-recursive` (defined
> under `$(am__recursive_targets):`). The command `make all-recursive` fails
> due to the Texinfo manual not building, and does not try building other
> targets because it wasn't run with the flag -k.

Minor corrections:

        > he runs `make -k [all]`, which runs `make all-recursive`

        You should say 'which would run' rather than 'which runs'.
        Since the prerequisites of 'all' are not met, the recipe (which
        consists of `make all-recursive`) never runs.

        > The command `make all-recursive` fails
        > due to the Texinfo manual not building,

        Not correct.  What is failing is a prerequisite of 'all', which
        results in its recipe (`make all-recursive`) not being run at
        all.

        > and does not try building other
        > targets because it wasn't run with the flag -k.

        Even with -k it doesn't build.  The reason is that -k allows
        other targets to continue building if their respective
        prerequisites are met.  If a prerequisite is not met, the target
        cannot run.  I'm not sure if `make -i` might help (it depends on
        how the recipes are defined).  Maybe the only solution is to
        touch(1) the files.

> Because the dependencies of
> all do not include anything outside BUILT_SOURCES (which seems to contain
> stuff relevant to gnulib), the Texinfo manual, and some helper targets,
> there is nothing more the `make -k` can do and so exits.

Actually, there's something more:

$ grepc -xmk -tr -n all Makefile
Makefile:6773:all: $(BUILT_SOURCES)
        $(MAKE) $(AM_MAKEFLAGS) all-recursive
Makefile:16742:all: $(GROFF_INFO) $(GROFF_TXT) $(GROFF_HTML) $(GROFF_DVI) 
$(GROFF_PDF)
Makefile:17140:all: font/devpdf/stamp
Makefile:17406:all: charset.alias ref-add.sed ref-del.sed
Makefile:17884:all: tmac/stamp-wrap
Makefile:17964:all: generate_man_files

> `grep -iw recursive $(find -name '*.a[cm]' -or -name '*.m4')` does not find
> anything substantial, so this is introduced by autotools. Web search does
> not reveal any official documentation on this matter, only a page at
> autotools.info (unofficial resource) entitled "Non-recursive Automake",
> but this only advises the use of a single Makefile.am that includes all
> the other *.am files without a single word about the auto-generated
> *-recursive make targets.
> 
> Conclusion: automake introduces recursive make into the build process.
> I haven't found any documentation on how to disable this. If anyone has
> the patience to hear more about autotools, I suggest taking this up to
> the autotools mailing list. I for sure don't.

I don't either.  I've had some discussions with autotools people, and
they all end up in "you're holding it wrong".  When so many people are
holding it wrong, maybe the tool isn't so well designed...

Next time I see a blackboard, I'll write many times

        autotools are bad.
        autotools are bad.
        autotools are bad.
        ...

Branden, if you ever feel like changing the build system to a pure GNU
make(1)-based one, I'm voluntary for writing it from scratch.


Have a lovely new year!
Alex

>     _______________________________________________________
>   {savane: user = 296833; tracker = bugs; item = 66583}

-- 
<https://www.alejandro-colomar.es/>

signature.asc
Description: PGP signature