On Jul 14, 2007, at 5:07 PM, Ian Lynagh wrote:
On Fri, Jul 13, 2007 at 04:56:44PM -0400, Peter Tanski wrote:
For the libraries it is serial but necessarily so in most cases (most
others depend on base). My last question to Ian was whether I could
make the internals for each library--boot, configure, makefile,
build--independent but I don't think that is possible, either, since
the Setup step may require that a previous library is available. So
now that I think about it maybe I can't make the internals
independent.
The problem I couldn't see how to nicely solve is this:
When you run make, libraries should be built in a valid order,
possibly
in parallel. You can do just this part with
configure.library.unix: build.library.base
etc.
Now suppose you make changes to the unix library and want to
rebuild it.
You run "make build.library.unix", but this time we don't want make to
build base again (although actually this isn't nearly so expensive now
that we are using makefiles, rather than ghc --make, to build base).
We could do this if we could write
$(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.% . 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.$*
Concerning rebuilds, if Make can see all the targets individually, as
files, then you should be able to dispense with the build-stamp
files. 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. 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
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. (Using $(eval ) makes this easy since I only have
to write such rules once, without resorting to pattern rules.) Make
would see all the targets and their dependancies it would build
everything unix depends on and then configure unix; since base is
already built it would not rebuild base if you later invoked 'make
build.library.unix'.
In any case, there aren't any configuration-time dependancies between
libraries? If you don't know I will go through the configure.ac
files (I have already for some--checking where mingw_HOST_OS might
conflict or coincide with windows_HOST_OS). If there aren't any,
then by setting different lists of independent libraries they will be
built in parallel:
BASE_SUBDIRS := base ...
LATER_SUBDIRS := unix ...
$(foreach bsubdir,$(BASE_SUBDIRS),$(eval $(call mkrule_one_Library,$
(bsubdir))))
-- these are independent
$(foreach lsubdir,$(LATER_SUBDIRS),$(eval $(call mkrule_one_LLibrary,$
(lsubdir))))
-- these have a special rule where they depend on the $(BASE_SUBDIRS)
Does this sound feasible?
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
