Loading object API feedback

[Mohammad Akhlaghi]

Dear maintainers of GNU Make,

I have recently implemented the Loading object API of Make in GNU 
Astronomy Utilities (Gnuastro) for special functions that are often 
useful in our high-level Makefiles (for astronomical data analysis: to 
organize calls to Gnuastro's command-line programs).

I have really enjoyed this API, and it will greatly help to simplify our 
data analysis Makefiles, and make them more optimized in speed also. 
Therefore, before getting to the issues I have found, I wanted to thank 
you for this very useful feature in GNU Make :-).

While I was implementing this interface, some issues came up that I 
wanted to share with you:

1. Regarding the "Consider using GNU Guile instead": From my perspective 
(as the author of a program/library written in C), this interface is far 
better than Guile! Since I don't currently know Guile, it would take me 
a long time to learn it (learning Guile has already been on my to-do 
list for more than 5 years, but I have never had the chance to invest 
time on it: there are too many more urgent things I need to invest time 
on). However, I implemented the 'load' feature in Gnuastro in half a 
day, and already several Gnuastro power-users are using Gnuastro's new 
library to load in Make.

2. At the start of the "Loading Dynamic Objects" section in the manual 
[1], it is mentioned that this is currently under "technology preview" 
phase. To help projects that depend on it (which now includes Gnuastro), 
it would be good that you add a macro in 'gnumake.h' specifying a 
certain version for this API (that is incremented any time there is no 
backward compatibility). In this way, at Gnuastro's './configure' step, 
we can check this version macro on the user's system and make necessary 
modifications for what should be compiled for which user.

3. When trying the example in the manual [2], my compiler was warning 
that the 'argc' argument of 'gen_tmpfile' should be 'unsigned int'. 
However, in the manual's example, it is simply 'int'. When I look in the 
source of 'gnumake.h' ([3]), I see that it is indeed 'unsigned int'.

4. I have noticed that the 'max_args' argument of 'gmk_add_function' 
isn't being checked! For example if I change the recipe to 'all' in the 
example Makefile to the line below, it won't complain:

all:
        @echo Temporary file: $(mk-temp tmpfile., abc)

It will also print an un-reasonable output:

Temporary file: tmpfile., abcCYB4I8

While it should have been:

Temporary file: tmpfile.CYB4I8

On the other hand, when I modify 'gmk_add_function' for a minimum and 
maximum number of 2 arguments, giving only a single argument cases this 
error:

Makefile:2: *** insufficient number of arguments (1) to function 
'mk-temp'.  Stop.

It would be good if the a similar error message was printed for 
situations that the user gives more arguments than the expected.

5. More generally, I see that many (+200) commits have been made in Make 
since the last stable release of version 4.3. Maybe some of the issues I 
report here have been fixed in all those commits. When do you plan to 
make the next Make official release (we extensively use GNU Make in our 
data analysis pipeline, and would love to use the more stable and 
optimized version that has so many improvements).

Thanks again for all the wonderful work in GNU Make,
Cheers,
Mohammad


[1] https://www.gnu.org/software/make/manual/html_node/Loading-Objects.html
[2] 
https://www.gnu.org/software/make/manual/html_node/Loaded-Object-Example.html
[3] https://git.savannah.gnu.org/cgit/make.git/tree/src/gnumake.h#n29