[Top][All Lists]

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

Re: adding a third type of prerequisite

From: Christof Warlich
Subject: Re: adding a third type of prerequisite
Date: Sat, 22 Jan 2011 19:41:28 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101208 Thunderbird/3.1.7

On 22.01.2011 17:58, Paul Smith wrote:
I'm certainly open to discussing things like this, but offhand I don't
see this situation as generic and wide-spread enough to justify new
fundamental make syntax.  The situation described here is easily managed
with existing behavior, so I'd like to see a more compelling use-case.

In your example, where you know that you want to avoid a particular
header in a particular rule, all you have to do is use $(filter-out ...)
to remove it.

For example, change your rule to look like this:

         %.sum: *.c *.h ${SUM}
              ${SUM} $(filter-out $(SUM),$^)>$@
         %: %_*.c sum.h
              gcc $(filter-out sum.h,$^) -o $@

You can create generic variables if you like, such as:

         EXCLUDE_foo = bar.x baz.y

         foo: foo.c foo.h bar.c bar.h baz.c bar.x baz.y
                $(CREATE) $(filter-out $(EXCLUDE_$@),$^)>  $@

or similar.

Agreed, for this example, filtering out would be a good alternative.
And even if I do not really know all the dependency-only prerequisites,
e.g. because they were added by a generic dependency generation
tool like David Boyce 's "audited objects", it will most probably be
possible in 99% of all real world cases to get arround with filtering
the other way round, i.e. with $(filter ...).

Hence, the points left over to argue for my suggestion are:

    - the 1% (or maybe even less) cases where filtering doesn't work well

    - assuming that "dependency-only prerequisites" would start with a /
in the same way as "order-only prerequisites" start with a |, a rule like

    %: %_*.c / sum.h
            gcc $^ -o $@

    may look a bit more readable than

    %: %_*.c sum.h
            gcc $(filter %.c,$^) -o $@

    particularly when the dependency only prerequisites have been added
    automatically elsewhere by a dependency generation tool, so that
    the need for the filtering may not be very obvious to a reader of the

    - the desired feature addition is fully backward compatibe: it doesn't
    break anything as long as it is not used

But anyhow, while I would still appreciate the described feature, mostly
because of the better readability in the context of an automated
dependency generation tool, I could also live without having it. In any
case, thanks for taking the time reading and for your valuable feedback.

reply via email to

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