[Top][All Lists]

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

[bug #51309] Determination of a file list from a single folder without c

From: Paul D. Smith
Subject: [bug #51309] Determination of a file list from a single folder without changing the working directory
Date: Sun, 2 Jul 2017 12:24:30 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

Follow-up Comment #5, bug #51309 (project make):

I understand what you are suggesting.

But I don't see any need to add new capabilities for this when the existing
features of GNU make can already give these results.

The only reasons for it that I can see would be (a) you prefer to do it this
way rather than the currently supported method of post-processing the wildcard
results, or (b) there's a significant performance benefit to avoiding the
extra processing.  For (a), I'm not inclined to create new capabilities just
for this reason.  For (b), I seriously doubt that there will be any measurable
performance difference in a real makefile.

If you can show an example where there _is_ a significant performance
difference then we can discuss that.

To be clear, my attitudes on makefile syntax are that (1) it's already complex
and there are already a lot of features, complexities, and "gotchas", (2)
adding new features in a backward- and POSIX-compatible way is difficult due
to the relatively free-form syntax of makefiles, and (3) features combine in
ways that are multiplicative, not additive, which greatly increases the
potential for incorrect interactions, bugs, and the testing needed to support

Thus, my initial answer to adding new capabilities is almost always going to
be "no".  It requires a clear improvement in power (not just syntactic sugar)
and a reasonable syntax that makes sense and doesn't break lots of existing
makefiles to clear that hurdle and get to "maybe" or "yes".


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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