On Wed, Dec 10, 2008 at 10:35 AM, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > On Wed, 10 Dec 2008, NightStrike wrote: > >> If automake has the ability to flatten the += syntax so that >> non-portable make advances can be used, why can't the same logic apply >> to wildcard usage? The biggest argument against it that I've heard is >> that it is a GNU-only option. However, I've suggested in the past >> that it'd be great if Automake can just process the wildcard and >> output the Makefile.in accordingly. It sounds like my suggestion >> wasn't that wild afterall if Automake can do this currently for things >> like +=. > > Automake is written in Perl, which is a very powerful scripting language. > Of course it could easily be extended to do such a thing. > >> When you have a library with 357 source files, the list in Makefile.am >> becomes unwieldy. > > I think that the fear is that the package will accidentally end up with 356 > or 358 source files but that exactly 357 are required. There is the idea > that software should be constructed by design rather than by accident.
Shouldn't the onus be on me, as the project maintainer, to accept that risk and craft the wildcards properly? I for one would wager heavily that the probability of that being a problem is FAR less than the current problems of maintaining the source file list. Doing it manually has already proven so error-prone as to cause significant lost time. What I guess is missing here is that I am not advocating that certain desirable extensions be *required*, just that they be *available*.
