Hi Peter,
On Sat, Jul 14, 2007 at 07:43:49PM -0400, Peter Tanski wrote:
>
> On Jul 14, 2007, at 5:07 PM, Ian Lynagh wrote:
> >On Fri, Jul 13, 2007 at 04:56:44PM -0400, Peter Tanski wrote:
> >
> > $(foreach SUBDIR,$(SUBDIRS),build.library.$(SUBDIR)): \
> > build.library.% build-stamp.library.%: ...
> > <commands>
> > touch build-stamp.library.$*
> >
> > configure.library.unix: build-stamp.library.base
> >
> >but make complains
> > *** multiple target patterns. Stop.
> >
> >It might work if we get rid of the first line (the foreach), but
> >I'm not
> >sure if other things would break if we did that.
>
> The problem with the $(foreach ) is the overlap between build.library.
> $(SUBDIR) and build.library.% .
Actually, the problem is that we're only allowed one pattern in the
middle section (which should match the targets in the first section).
> For example, with unix, this expands
> to:
>
> build.library.unix : build.library.% build-stamp.library.% : ...
>
> If you got rid of build.library.% (since it is already covered by the
> $(foreach)) you should be o.k. and have no overlap, although I find
> the syntax:
>
> target1 : target2 : target3
> [commands]
>
> a bit sketchy.
>
> You could do this:
>
> $(foreach SUBDIR,$(SUBDIRS),build.library.$(SUBDIR)) build-
> stamp.library.% :
> <commands>
> touch build-stamp.library.$*
I think you're misunderstanding the syntax. It's using "Static Pattern
Rules", which restricts what the pattern is allowed to match to the list
of targets given. i.e. rather than the normal
<target patterns> : <prereqs>
we have
<targets> : <target pattern> : <prereqs>
I'm not sure if we actually need the explicit target list for the
libraries Makefile; it might be worth removing it and seeing if it
works.
> Concerning rebuilds, if Make can see all the targets individually, as
> files, then you should be able to dispense with the build-stamp
> files.
I'm not sure what you mean. There isn't a file we can use to know if
configure has been run, for example, which is why we use stamp files.
We don't want to rerun configure each time we remake a library.
> You could force a rebuild by making the PHONY rebuild.$
> (SUBDIR) a dependancy of FORCE: but then it might still rebuild base
> if you want to force a rebuild of unix--I haven't used FORCE before,
> though I have used 'make -o file'. I'm not sure why you would want
> to do this often--if Make can 'see' everything then you should be
> able to say 'make unix' and Make would only rebuild changed files as
> it normally does.
make can't see everything as each library has a separate Makefile.
Some things are also still hidden by the Cabal abstraction.
> Of course, this means the libraries should be in
> the Makefile based on their library name (libunix.a) and the
> directory names should be declared PHONY.
>
> PHONY: unix
>
> libunix.a :
> [commands]
>
> unix: libunix.a
This doesn't work:
Suppose you make some changes to the unix library, and run "make unix".
make checks that libunix.a is up-to-date and, seeing as it has no
dependencies, concludes that it is. This you can't rebuild the library.
My make doesn't have the FORCE you talk about above, so I'm not sure if
that solves the problem. I can't see how it would without also meaning
that base always gets rebuilt, though.
> The way I was proposing to change libraries/Makefile, I would have in
> the end made PHONY targets for the library names
> (configure.library.unix, above) and add the library file-names as the
> command-targets.
This sounds like it would rerun configure for each change to the library
sources?
> $(foreach bsubdir,$(BASE_SUBDIRS),$(eval $(call mkrule_one_Library,$
> (bsubdir))))
Hard to say without knowing what you plan to generate, but like Simon,
I'm not keen on the idea of generating the make rules. It would make it
a lot harder for people to understand, I think.
Thanks
Ian
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
