Re: Make feature rq: Non-pattern rules with multi-target commands

[Henning Makholm]

Scripsit "Paul D. Smith" <address@hidden>
> %% Henning Makholm <address@hidden> writes:

>   hm> Here is why I need it: I use a compiler, `mosmlc', that reads a
>   hm> `*.sml' source file and write a `*.uo' file with object code and a
>   hm> `*.ui' file with a machine-readable interface summary.

> OK... I don't see why the standard pattern rules won't do the trick
> here?

>   %.uo %.ui : %.sml
>         mosmlc $<

My main reason is that the command is not the same in each case. There
are a number of other dependencies that also need to go on the command
line - in the right order! - and in some cases special flags are
necessary.

Philip Guenther pointed me to the possibility of letting part or all
of the command be a target-specific variable, and I agree that that
solution is better than the solution I use currently, but I'm still
not quite comfortable:

1. Target-specific assignment cascade to prerequisites, but here I
   actually only want them for one particular target. I can work
   around them by making sure that all prerequisites have their own
   target-specific assignment, but I foresee seriously hard-to-track
   bugs if somehow I get it wrong or fail to maintain the invariant
   when the Makefile changes.

2. Ever ambitious, what I'm writing is actually a Makefile *generator*
   that I hope will be of use to other people who use the same
   compiler. They would use my tool to create rules for compiling
   .sml files and include the resulting Makefile fragment in their
   own makefile. I'm not completely comfortable with having the
   generated fragment include a generally applicable pattern rule;
   it would be nice to say that the generated fragment is well-behaved
   and does not include stuff that could affect how Make processes
   filenames that the user didn't ask to have included.

>   .foobar.temp: foobar.sml
>         mosmlc $<
>         touch $@
>   binary: .foobar.temp

> Gross, but it usually works.

Only when nothing (or at least nothing with commands) depends on
`binary': since the empty command does not change its timestamp, make
will assume that it is not necessary to to futher recompilations even
if `binary' did change as the result of the mosmlc command. Here is
what I get, testing your construction:

pc-043:~/tmp/foo$ cat Makefile
final: interm
        cat interm > final
interm: stamp
stamp: source
        cat source > interm
        touch stamp

pc-043:~/tmp/foo$ ls -lrt
total 20
-rw-r--r--    1 makholm  user            4 Oct 21 01:01 interm
-rw-r--r--    1 makholm  user            4 Oct 21 01:02 stamp
-rw-r--r--    1 makholm  user            4 Oct 21 01:03 final
-rw-r--r--    1 makholm  user           97 Oct 21 16:16 Makefile
-rw-r--r--    1 makholm  user            4 Oct 21 16:17 source
pc-043:~/tmp/foo$ gmake final
cat source > interm
touch stamp
pc-043:~/tmp/foo$ gmake -v
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
pc-043:~/tmp/foo$ 

In this thest run, `interm' changes in the command for `stamp', but the
command for `final' does not get run as it should (at least according
to the user's intentions). I'm not conversant enough with the POSIX
specs to judge whether the `final' commands *ought* to be run here or
not. FWIW, GNU make's behavior is consistent with SunOS 5.7 but not
with HP-UX 10.20 and DEC OSF V.40.

> Could be.  Unfortunately I know little to nothing about the changes
> Cygnus has made to their version of GNU make.

I'm not sure they've made any changes to the make source at all, but
the stat() call (& friends) in their libc try to emulate Unix
semantics for a file system that is, at its core, case-insensitive.
Not always with complete success. So it's probably not make's fault
but it is an effect I have to take into account nevertheless.

>   hm> If not, would a patch that adds an explicit syntax for non-pattern
>   hm> many-targets-at-once rules have a chance of being considered?

> Sure; this feature is definitely on the list of "really should be done".
> It's probably not even all that difficult; one of the main problems will
> be coming up with the right syntax to express it in the makefile.

That was my analysis too. :-)

-- 
Henning Makholm                        "Nej, hvor er vi altså heldige! Længe
                                      leve vor Buxgører Sansibar Bastelvel!"