By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,799 Members | 1,356 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,799 IT Pros & Developers. It's quick & easy.

[Makefile]How can I deal with multi-dirs?

P: n/a
I have a project with the following dirs:
---------------------------------------------------------------------------------------
+src
|-proj0
|-program1
|-program2
|-proj1
|-program1
|-program2
|-program3
|-program4
|-proj3
|-program1
|-program2
|-program3
....
|-proj9
-Makefile
+include
-README
+lib
|-lib1
|-lib2
---------------------------------------------------------------------------------------
There are 10 project-dirs here in src, named proj0-proj9. Each project
has several program_dirs which containing some .c files
All .h files are under include in the top dir, the same as src.

I would like to write a makefile, which can help me compile all the .c
files and generate an executable file for each *program*. Considering
there are several independent programs in each project, the work
should be done within a single makefile at the top dir.

How can I deal all the programs under each project in a single top-
level makefile?

Thanks!
Apr 1 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
fnegroni wrote:
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.
I do believe that the best way is to simply rely on an automatic makefile
generator. For example, automake does a wonderful job at this multi-dir
project stuff.

But yes, it's OT.
Rui Maciel
Apr 1 '08 #2

P: n/a
fnegroni wrote:
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.
I do believe that the best way is to simply rely on an automatic makefile
generator. For example, automake does a wonderful job at this multi-dir
project stuff.

But yes, it's OT.
Rui Maciel
Apr 1 '08 #3

P: n/a
On Apr 1, 4:09*pm, Antoninus Twink <nos...@nospam.invalidwrote:
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.
Apr 1 '08 #4

P: n/a
fnegroni wrote:
Antoninus Twink <nos...@nospam.invalidwrote:
.... snip ...
>
>I believe you've read some stupid polemic about recursive Makefiles
having serious flaws, and have bought into it hook line and sinker.

Maybe.
Twink is a pure troll. Ignoring and plonking is recommended.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Apr 1 '08 #5

P: n/a

"M.Liang Liu" wrote:
I have a project with the following dirs:
----------------------------------------------------
+src
|-proj0
|-program1
|-program2
|-proj1
|-program1
|-program2
|-program3
|-program4
|-proj3
|-program1
|-program2
|-program3
....
|-proj9
-Makefile
+include
-README
+lib
|-lib1
|-lib2
---------------------------------------------------
There are 10 project-dirs here in src, named proj0-proj9. Each project
has several program_dirs which containing some .c files
All .h files are under include in the top dir, the same as src.

I would like to write a makefile, which can help me compile all the .c
files and generate an executable file for each *program*. Considering
there are several independent programs in each project, the work
should be done within a single makefile at the top dir.

How can I deal all the programs under each project in a single top-
level makefile?
<OT>
Don't do that. That's called "micromanaging", and is just as
idiotic when done by make as when done to you by your boss.

Instead, if you have 37 "programs" in 5 "projects" in 1 "workspace",
write 43 makefiles, one for each node in your tree, and one at top
level. The top-level makefile calls the "project" level makefiles,
and they in-turn call the "program" level makefiles.

Advantages:
1. Each makefile is very small and simple and easy to write and
maintain.
2. Changes made at any one node necessitate updating (at most)
the 1 makefile for that node.

This is true regardless of programming language. For more help,
ask about this in "comp.programming", "comp.unix.programmer",
and "gnu.utils.help".

Save the "comp.lang.*" groups for questions about their particular
LANGUAGES. (That's what the "lang" in "comp.lang.*" stands for.)
</OT>

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant
Apr 6 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.