This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: Recursive make harmful
- To: Richard Boulton <richard at tartarus dot org>
- Subject: Re: Recursive make harmful
- From: Alexandre Duret-Lutz <duret_g at lrde dot epita dot fr>
- Date: 01 Jun 2001 15:53:26 +0200
- Cc: tromey at redhat dot com, Automake List <automake at gnu dot org>
- List-Id: Discussion list for automake <automake.gnu.org>
- Organization: LRDE/EPITA http://www.lrde.epita.fr/
- References: <87vgmhsdo2.fsf@creche.redhat.com><mvbpucoa7b6.fsf@phobos.lrde.epita.fr><20010601131301.A808@ixion.tartarus.org>
>>> "Richard" == Richard Boulton <richard@tartarus.org> writes:
Richard> On Fri, Jun 01, 2001 at 11:16:45AM +0200, Alexandre Duret-Lutz wrote:
>> There is something nice about having one Makefile.am in each
>> subdirectory, it's that it helps to make selfcontained and
>> reusable modules.
Richard> What is being advocated is that we keep having Makefile.am's in each
Richard> separate directory (there's no question that this is desirable for
Richard> maintainability), but that automake combines them all together into a
Richard> top-level Makefile.in, rather than building Makefile.in's in each
Richard> directory.
Sorry, I was answering to Tom's comment regarding what's possible to
do with *current* CVS automake.
>> But that's really painful. Does s.o. has another idea? (I'm
>> thinking that maybe automake could figure `bar/foo' from the
>> include path, and do something helpful with that...).
Richard> With separate Makefile.am's in each directory,
Richard> automake should be able to figure the bar/foo out from
Richard> the directory paths. The user shouldn't have to worry
Richard> about what the path to the top-level is.
Is this really possible? Makefile.am files may contains rules
which need to be patched if you move them at another level.
Somehow, each target should be written in a relocatable way,
taking care of directory paths.
--
Alexandre Duret-Lutz