On Wed, 2002-04-10 at 18:26, Tom Tromey wrote: > Also wildcards wouldn't interact well with some automake features. > That's because we need to do certain things statically to work around > problems and missing features in vendor makes. > > As an example suppose you want to use per-executable CFLAGS. This > feature won't work with wildcards since we must generate an explicit > rule for each .o in the executable. With wildcards there is no way to > know when we need to regenerate the Makefile (we could do it every > time, but first that would be horrible and people would complain, and > second it only works with GNU make anyway).
Surely one thing we could do is to implement wildcards that are evaluated at the time that automake is run. This would be portable, since automake would be doing the work, and Perhaps the best way to do this would be to add support for the $(wildcard PATTERN...) function in automake variables, which would evaluate the PATTERN against the source directory, and expand to the names of all the matching files. Or perhaps call it $(amwildcard ...) to avoid breaking existing Makefile.ams which use this (and depend on GNU make). It is still true that it would be impossible to ensure that the Makefile.in is regenerated when a new source file is added, but I would imagine it is rare to add a new source file to a project without modifying any of the existing source files. I think this would be a worthwhile addition: if I ever get time to implement $(patsubst ) and other functions, I shall try implementing this one too. -- Richard
