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

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!

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

fnegroni wrote:
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

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

fnegroni wrote:
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

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

On Apr 1, 4:09*pm, Antoninus Twink <nos...@nospam.invalidwrote:Maybe.
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?
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.

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

fnegroni wrote:.... snip ...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

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

"M.Liang Liu" wrote:
<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