Scripsit "Paul D. Smith" <[EMAIL PROTECTED]>
> %% Henning Makholm <[EMAIL PROTECTED]> 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!"
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
