[H-GEN] gnu make command-line target ordering problems?

[Anthony Towns]

On Tue, Oct 19, 1999 at 02:21:08PM +1000, Ben Carlyle wrote:
> The old make system would take roughly 10 seconds per invocation, so

Lovely.

> it was a major concern to keep sequential orderings on a single
> command-line.  Still, the scripter in me wants to minimise invocations
> even with gnu.

Sure.

> Consider this situation:
> A single template library is shared between all object files in a
> directory.  Due to bugs in the compiler handling of templates, the
> template database must be entirely eradicated before objects are
> built.

I don't get this. How is the template library built: all at once, or by
adding bits at a time? Is it before/after/concurrent with building the
.o objects? Do the .o files depend on the template libraries as well as
the source, or do they just have to be linked together later?

Actually, I'm doubly confused. I assume the template libraries are
pseudo object code for templates you define in .c files instead of
.h files? In that case I'm not sure why you don't have:

	templatelib : temp1.c temp2.c temp3.c
		rm templatelib
		cc --build-templatelib $^

	foo.o : foo.c
		cc -c foo.c

or:

	templatelib : temp1.c temp2.c temp3.c
		rm templatelib foo.o
		cc --build-templatelib $^

	foo.o : foo.c templatelib
		cc -c foo.c

> Due to a problematic design, all templates must be shipped
> to a central location immediately after compilation.

Weird.
 
> Would I be right in believing the following solution is what you
> suggest?
> 
> Solution 2:  Your suggested approach (the one I tried before Solution 1)
> 2a ---
> objects: ${OBJS}
> 	ship_templates
> clean_out_templates:
> 	clean_templates
> include ${OBJS:%.o=%.d}
> ---
> or perhaps
> 2b ---
> objects: clean_out_templates ${OBJS} ship_all_templates

Having dependencies on both `clean' and `ship' concurrently is
fundamentally wrong. Even if it would work in sequential make.

> clean_out_templates:
> 	clean_templates
> ship_all_templates: ${OBJS}
> 	ship_templates
> include ${OBJS:%.o=%.d}
> ---
> 
> where
> foo.d is
> ---
> foo.o foo.d: clean_out_templates foo.c foo.h bar.h
> ---

No, I wouldn't have a dependency on `clean_out_templates'. I wouldn't
(don't) use .PHONY targets as anything but convenient aliases.

The `solution 1' way you quoted originally is the Most Proper of these;
it's only problem is it has two levels of dependencies. That might be
as good as you can get, if you really do have to clean out and rebuild
an entire directory at once, rather than just being able to update
the appropriate files.

Oh, and note that in a Makefile you can do:

	make pre.foo
	make do.foo
	make post.foo

instead of having to type those stupid && thingies. Similarly you can
set -e in a script to make it abort as soon as anything fails.

> This fully expresses the dependancies,

This is where I'd differ: foo.o doesn't `depend on' clean_out_templates,
it's just some extra stuff you have to do in order to rebuild foo.o,
and as such should merely be an extra command to build foo.o. So I'd say
this doesn't express the dependencies correctly, let alone fully. YMMV.

>      It doesn't solve the problem of
>      building a single object file and having it's templates
>      shipped (as my solution does not).

I wouldn't bother with this, but you could do it by, eg:

	.shipped.% : %
		ship $^
		echo "Shipped at:" $(date) > $@

and make .shipped.% your target for your `do.foo' .PHONY. (At least if
you're only shipping a few things)

Alternately, if you're shipping lots of stuff, you could just add the
`ship' command to your actual build instructions.

(Personally, I'd rather have everything shipped on a successful commit,
so it doesn't contaminate anyone else until the developer's comfortable
that it works, but YM obviously does V)

> > > Now you'll argue that I should be running these as shell scripts,
> > > and that could work at the top-most level... in fact that is
> > > truely what I am doing. [...] At every level life is
> > > simple, despite the size.
> > ...in which case I don't see what the problem is.
> As you have already said... it doesn't fit well with the make
> philosophies.  It also requires a helluva lot of make executions
> if you can't specify them one after the other on a single
> command-line.  (I'd estimate ~2500 or 3000)

I don't think it fits that badly with the make philosophy, it's just
a two level hierarchy rather than flat, which means make can't do
as much cleverness as perhaps it might.

And, of course, if you could get it down to a nice one level,
non-recursive, heirarchy that's one make invocation, instead of 800 to
1000. :)

> > (And ad hominem attacks are pretty weak. Tsk.)
> 'course they are, but it doesn't mean they don't apply ;)

Whether they apply or not, doesn't make them relevant.

> OTOH, when a company invests 100k on a CM system there is a certian
> political momentum, especially after a similar amount again is
> invested to get it only to this state.  It does certain things
> rather well, however it falls short of my expectations of mature
> product in many ways.

Heh.

Either that or, *sigh*. Take your pick.

Cheers,
aj, who thinks fixing bugs in your compiler and CM tool by changing
    make is slightly deranged. Understandable, but still deranged.

-- 
Anthony Towns <aj at humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 434 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/19991019/e7c107ed/attachment.sig>