bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnulib-tool.py consider automake_subdir=false support


From: Mitch Capper
Subject: gnulib-tool.py consider automake_subdir=false support
Date: Thu, 1 Jun 2023 12:40:54 -0700

I am doing some quick and dirty things currently for compiling a slew of (mostly) gnu software of Windows.   I hope to have some semi-quality patches to submit soon enough.  

I have been very grateful for gnulib-tool.py as it results in some massive bootstrap speed improvements (over 10x) on Windows.  

It doesn't support --automake_subdir (yet) which given its complexity is understandable.   The inverse however of not needing subdir support could be improved (seemingly?) easily.

As mentioned, there is a good bit of logic around subdir enabling in gnulib-tool  but when it is not enabled it seems only one thing happens:
sed_eliminate_NMD='/@NMD@/d;s/@!NMD@//'
and is added to the list of sed scripts against the generated output.  Without this I have seen several libraries that can't use gnulib-tool.py because the makefile is left with invalid syntax.

Now I am by no means an expert on any of this, maybe it does something else I am missing.  What I can say though is I have had great success on libraries that don't need subdir support working by running that sed command myself on the makefiles during bootstrapping (while using gnulib-tool.py).

It is a shell command which gnulib-tool.py does generally avoid (part of why it's so fast!) but I do see sed being used in a few other places.  Of course I could likely put a patch together to emulate that in python as well.

A potential issue would be if there was someone using gnulib-tool.py for subdirs (but not passing the automake_subdir flag to the tool as it errors out if you do).  They would (i would guess) have to do some manual hacking to get it working, but this could have a negative impact for them.  I do think that this behavior is the same as the bash variant of the tool though so I wouldn't think it would be considered a breaking change.


~mitch (they, them)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]