Subject: Re: Status of autoconf framework
From: Frodo Looijaard (frodol@dds.nl)
Date: Mon Jun 11 2001 - 16:58:41 CDT
Hubert Figuiere wrote:
>
> According to Frodo Looijaard <frodol@dds.nl>:
>
> Frodo,
>
> thanks for all the improvments.
>
> > I have put some work into the autoconf framework. It should now be workable
> > for Unix users, I think. It works for me now :-)
>
> Each make it relinks libwv and the wv utilities.
> I haven't had the time to look at it yet, and it looks like you are better
> than me with autoconf stuff :-)
It is because libwv.a depends on several 'phony targets' (even though they
are not marked as phony). For example, it depends on OLEDECODE, though
there is no real file OLEDECODE. Everytime make is run, it tries again
to resolve this dependency: so it first runs the OLEDECODE rule, and
then remakes libwv.a.
From the make manual:
A phony target should not be a prerequisite of a real target file;
if it is, its commands are run every time `make' goes to update that
file. As long as a phony target is never a prerequisite of a real
target, the phony target commands will be executed only when the phony
target is a specified goal
To solve the problem properly is quite hairy. You can't have libwv.a
depend on $(EXPORTER) XMLPARSER $(ICONV) $(MAGICK) OLEDECODE or LIBOLE2.
One way to do this is to have a target higher-up (for example, target `all'
itself) that calls them. The downside of this is that if you do a direct
`make libwv.a', you won't get any dependency checking anymore.
I don't think there is an easy fix-and-get-it-to-work-right solution here,
without rethinking your build system. One 'easy' way to fix this is
to use automake and libtool; though implementing them can be somewhat
hard, they will automatically solve issues like this. If you want to do
it by hand, as I assume, I would suggest making intermediate archives
for each subdirectory, and then linking these together. This will
probably make life somewhat simpler, though it will not really solve
the dependency issue. One approach I have choosen in the past in cases
like this is to use the one Makefile approach: combine fragments in
each directory to create one (quite large) Makefile, which can do all
dependencies directly. Though this works great, in greater projects make
gets quite slow, and it would again mean a revamp of your build system.
For more information on recursive makes and the problems they lead to,
read the paper 'Recursive Make Considered Harmful' by Peter Miller:
http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html
Sorry for not offering any easy solutions here, but it is a hard problem
that usually only has hard solutions.
Good luck,
Frodo
-- Frodo Looijaard <frodol@dds.nl> PGP key and more: http://huizen.dds.nl/~frodol Defenestration n. (formal or joc.): The act of removing Windows from your computer in disgust, usually followed by the installation of Linux or some other Unix-like operating system.
This archive was generated by hypermail 2b25 : Mon Jun 11 2001 - 16:59:11 CDT