help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: suddenly, "recursive make considered harmful" makes piles ofsense


From: Alessandro Vesely
Subject: Re: suddenly, "recursive make considered harmful" makes piles ofsense
Date: Tue, 18 Jan 2005 17:27:38 +0100

Noel Yap wrote:
> 
> IME, it's best to have a GNUmakefile in each directory (so anyone can do a 
> gmake
> within any directory) and a, say, GNUprivate.mk file within each directory 
> (that
> contains the non-common stuff).

The problem of recursing becomes apparent when there are inter-directory
dependencies. Did you ever wish, while writing a makefile, that you had
at hand all the dependencies already specified for another directory?
In facts, writing recursively is easier and there is much more experience
with it than with single makefile builds.

> I've seen two philosophies on this:
> 1. gmake within any directory will build the entire project
> 2. gmake within any directory will build that directory and
> any subdirectories (a la recursive make)
>
> I personally lean towards the second philosophy

me too.

> which means that each GNUmakefile needs to include its corresponding
> GNUprivate.mk and its subdirectories' GNUprivate.mk's.

AFAIK, there is no recognized standard for writing these. Of course there
must be agreed variable naming conventions. However, should one code
each file name with a variable prefix in front of it? E.g.,

   TARGETS += $(PATH_TO_HERE)my_target
   $(PATH_TO_HERE)my_target : $(PATH_TO_HERE)my_obj1 $(PATH_TO_HERE)my_obj2

where PATH_TO_HERE is set to "this_subdir/" by the parent, or else is empty.
That contradicts rules 3 and 4 in <http://make.paulandlesley.org/rules.html>,
but there are no directives such as `include_and_cd' or even just `cd'.
There is vpath, but how do I know that a source file named just like mine
will never appear in some upper directory? Furthermore, many rules work
just smoothly when issued from the proper directory. I often write
`$(MAKE) -C' when all I wanted to say was `cd'.

> To minimize maintenance on GNUmakefile, a function is used that'll just
> shell out and execute a "find . -name GNUprivate.mk".

Otherwise, each GNUprivate.mk may include its subdirectories' GNUprivate.mk's.
The $(wildcard) fuction may come handy for this.

> HTH,
> Noel
> 
> Robert P. J. Day wrote:
> 
> > On Sat, 15 Jan 2005, Alessandro Vesely wrote:
> >
> >
> >>"Robert P. J. Day" wrote:
> >>
> >>>[...]
> >>>and it was just yesterday that it suddenly dawned on me how to make
> >>>this much simpler, and only after i started redesigning the structure
> >>>did it occur to me that this might be what miller's paper might be
> >>>talking about.
> >>
> >>It is not. Peter Miller's emphasis is about make being able to
> >>traverse the whole dependency tree the way it reckons, rather that
> >>traversing it a sub-tree at a time in the order dictated by the
> >>top-level makefile without ever being able to see the whole tree at
> >>once. E.g. using `include' rather than `$(MAKE)'.
> >
> >
> > yes, i see what you mean.  i hadn't actually finished the paper, but i
> > thought i could see what he was getting at.
> >
> > still, i think philosophically there's some common ground -- i'm
> > seeing a definite advantage in taking control of the lower-level parts
> > of the build process and pulling them back to the top of the tree so i
> > can control the entire process all at the top level (even to the
> > extent, as i described in my next posting, of controlling build
> > options of lower levels at the very top).
> >
> > i'll think on this some more.  thanks for the feedback.
> >
> > rday
> >
> >
> > _______________________________________________
> > Help-make mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/help-make




reply via email to

[Prev in Thread] Current Thread [Next in Thread]