|
|
On Apr 1, 4:09 pm, Antoninus Twink <nos...@xxxxxxxxxxxxxx> wrote:
> On 1 Apr 2008 at 12:20, fnegroni wrote:
> > I believe recursive makefiles have serious flaws and should be
> > avoided.
>
> I believe you've read some stupid polemic about recursive Makefiles
> having serious flaws, and have bought into it hook line and sinker.
>
Maybe.
> > In this case, if each project is standalone, each needs a Makefile and
> > then you might want a script to run all the makefiles in sequence.
>
> A "script", eh? But definitely not a top-level Makefile?
>
A Makefile to do what a script can do perfectly well? Why?
How does a top level makefile improve the situation. Surely it is the
individual makefile that knows whether a target needs recompiling or
not. Why would a top level Makefile do a better job than a script?
>
> > Also, a better source code file structuring also helps: I would place
> > all source files together in the same directory. After all, if they
> > are interrelated, what would be the advantage in splitting them about?
>
> > But that's my opinion. Yours may differ.
>
> It sounds like the OP's project consists of one or more libraries, and
> then some number of independent executables that link against these
> libraries. Separating the source files for each executable into its own
> directory seems perfectly reasonable to me.
Sure, but then why having recursive makefiles? If each project is
standalone, whether a library or executable, each Makefile is self
contained. Certainly not split.
If the different sources for the *same* executable were split across
directories, then a recursive makefile would save the use of relative
paths, but that's where IMHO it would be better to consolidate all
source directories for the same tool into one.
If one module is shared across two executable, shouldn't that be a
static library? I thought that's what they were meant for.
|
|