Hello Miles, thanks for the feedback. On 01/23/2013 07:54 AM, Miles Bader wrote: > Stefano Lattarini <stefano.lattar...@gmail.com> writes: >>> E.g., if I have a directory "foo" that has sources etc, and builds >>> some specific targets, then I can isolate the automake stuff for foo >>> by using an include file "foo/Makefile.am.inc" or something, and then >>> putting an appropriate include in the top-level Makefile.am. >>> >>> But it's a bit annoying, in that AFAICT, all filenames, etc, in foo's >>> Makefile fragment must explicitly include the directory name. >>> >> Yes, and this issue has come up several times already. Nobody has >> been bothered enough to attempt a patch, though, at least so far. >> >>> E.g., if it builds a library, "foo/Makefile.am.inc" might look like: >>> >>> libfoo_a_SOURCES = foo/oink.c foo/barf.c foo/barf.h ... >>> >>> For longish directory names, this can really bloat things up... >>> >> Someone (probably Eric Blake, but I'm not 100% sure) once noted that this >> issue could be mitigated with simple indirections with usual make macros: >> >> d1 = wow/a/very/very/insanely/long/directory/name >> >> wow_a_very_very_insanely_long_directory_name_prog_SOURCES = \ >> $(d1)/a.c $(d1)/b.c ... $(d1)/z.c > > Yes, that's the method I currently use, but it's pretty ugly, and kind > of fiddly -- you need to use a unique macro name for every subdir, > Yes, that is annoying and somewhat fragile.
> and practicality means probably using some variant of the directory > name for that... meaning you probably have longish variable names in > practice. > > Ugliness is better than "broken" but frankly I don't want it; one of > automake's big attractions for me is that it allows one to write > highly readable makefiles that are more easily maintainable because of > their relative simplicity and lack of boilerplate (which hinders > readability by obscuring significant content). Stuff like this feels > very similar to typical Makefile boilerplate, and I think makes for > more fragile, less maintainable Makefiles. > >> This is probably too automatic; but Bob Friesenhahn suggested Automake >> could recognize special substitutions, like %CURDIR% and %XCURDIR%, so >> that you could simply use in >> >> %XCURDIR%_prog_SOURCES = %CURDIR%/a.c %CURDIR%/b.c ... %CURDIR%/z.c > > This is less fragile, > Which is a step forward at least; and since it appears it might be very easy to implement and fit in the existing automake processing scheme, I'm willing to give it a try. Further improvements and refinement might go on the top of that. > but still pretty grotty, that's going to result > in makefile[-fragment]s that feel like they're full of boilerplate. > > Really, I'm thinking about something _more_ magic. > It might be nice to do so as a second step, but I'd rather not have the best be the enemy of the good; we can make the Makefiles less fragile *today*, and make them less "boilerplatish" tomorrow. > I want to write filenames as I think about them: > > ..something...: a.c b.c ... z.c > > If something that does automagic munging of all filenames in a > makefile fragment is too magic, at least maybe this could be done with > some sort of simple rewrite mechanism to at least automake the common > factor. > > E.g.: > > libfoo_SOURCES[libfoo/]: a.b b.c ... z.c > This could be "syntactic sugar" that we might add after the improvement suggested above; in fact, the two things could eventually compound to allow usages like: libfoo_SOURCES[%CURDIR%] = a.c b.c ... z.c > This sort of thing would have the advantage of being relatively > "stupid" (a simple explicit string rewrite), while still being able to > eliminate much of the redundancy... > I'm not opposed to the idea, but I see it as a second step, after the improvement we are discussing. A second step for which patches are, as usual, welcome :-) > Thanks, > > -miles > Thanks, and best regards, Stefano
