Eric Blake wrote: > > It does not require a modification of gnulib-tool. tests/macros.h is not > > different in principle than tests/nan.h; it's only used in more places. > > But that means listing tests/macros.h in more than 100 modules/*-tests files. > > There comes a point where a file is so ubiquitous that we might as well make > its presence automatic.
In the long term, I would like to see gnulib-tool's scope become broader: 1. Allow it to combine overrides from multiple --local-dirs, 2. Obsolete gettextize, autopoint, and possibly also libtoolize. For this to work, gnulib-tool needs to have no built-in knowledge about particular modules any more. That's one of the reason why the 'Notices' and 'Applicability' information were moved from gnulib-tool to the module descriptions. tests/macros.h is an incarnation of a particular coding style. Other people may want different macros, tests/macros2.h. That's one reason not do it in gnulib-tool. The other reason is consistency with other #includes: When you #include "foo.h" you know that you need to depend on the module 'foo' or have "foo.h" among the list of files. If we would make an exception for tests/macros.h, it would confuse people who try to understand how gnulib works. Bruno
