Re: shortest stem

[Paul Smith]

On Wed, 2009-09-23 at 16:39 +0200, Boris Kolpackov wrote:
> %-pic.o: CFLAGS := -g -fPIC
> %.o: CFLAGS := -g
> 
> foo-pic.o: foo.c
>       @echo $(CFLAGS)
> 
> This makefile currently prints '-g'. For pattern rules:
> 
> %.o: %.c
>       @echo normal
> 
> %-mt.o: %-mt.c
>       @echo multi-threaded
> 
> all: foo-mt.o
> foo-mt.c:
> 
> This makefile currently prints 'normal'. Changing the order of
> the patterns in both makefiles results in the expected behavior.

> I am wondering whether this should be enabled by default or only
> enabled on request.

I really hate having lots of flags and switches that change basic
behavior.  More to understand, more to test, more to learn, etc.

But, we need to make sure this change doesn't decrease the capability of
make in any important way before we turn it on.

> The implementation is quite compact and the 
> performance is unchanged (actually, the performance has improved
> slightly as a consequence of a bugfix I made in implicit.c). I 
> tested it on my project which has 884 pattern rules and 7361 
> pattern-specific variables (non-recursive build system).

I'm interested in your patch to implicit.c because I have a rather large
set of changes I'm just getting ready to commit, that reworks a bunch of
read.c and implicit.c (the whole struct idep thing is gone, etc.) to
reduce memory usage, and possibly improve performance.  Basically my
change will move the parsing of prerequisites back into read.c, EXCEPT
when the rule is a true candidate for secondary expansion.  This change
passes all the unit tests so I'm going to commit it (as soon as I get
the changelogs done) but I'd really appreciate it if folks with larger,
more complex secondary expansion environments would give it a whirl.  I
checked with valgrind and there are no memory errors, but I believe
there are some small leaks (some struct dep's not properly freed) which
I'll look into afterward.

> While the behavior is not exactly backwards-compatible, I don't
> think we actually specify anywhere in which order patterns are
> evaluated

We do, actually: the GNU make manual is quite clear that patterns are
processed in the order in which they appear in the makefile, and the
first matching pattern (where the prerequisites either exist or can be
built) is taken.

>  and I don't think anyone relies on the current behavior,
> except maybe accidently. On the other hand, I found a couple of
> emails in the archive where people were surprised by the current
> behavior and thought it was a bug.

Obviously it's hard to know who relies on the current behavior.

How does your patch manage for patterns that have different
prerequisites?  For example, what about:

        %.o : %.c
        %-d.o : %.y

? Today this ordering will always choose to build the .o from the .c
file because it appears first.  After the change, how will this work?

Similarly, what about multiple prereq patterns:

        %.o : %.a %.b
        %.o : %.a

In today's make the first one will be chosen as long as %.b exists (or
can be remade, but if it can be remade then the second will never be
chosen), otherwise the second rule will be chose.  We just had this
situation earlier this week on the mailing lists.

How does this change work here?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist