[Top][All Lists]

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

Loading object API feedback

From: Mohammad Akhlaghi
Subject: Loading object API feedback
Date: Sun, 28 Aug 2022 17:25:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0

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:

        @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,

[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

reply via email to

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