|
Home > Archive > Unix Programming > March 2006 > Building Library from Hierarchy of Makefiles
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Building Library from Hierarchy of Makefiles
|
|
| Michael B Allen 2006-02-05, 2:47 am |
| I have a project that consists of a few subcomponents. I'm pretty sure
I want the subcomponents in separate directories with their own Makefile
so that they are relatively self contained. For example, lets say I have
a library libfoo with subcomponents a and b, then the file arrangement
might look like the following:
libfoo-0.2.0/
Makefile
src/
f1.c
f2.c
f3.c
a/
Makefile
fa1.c
fa2.c
b/
Makefile
fb1.c
For a while this was working if each subcomponent directory's Makefile
created a pic.a archive of PIC object files. The top-level makefile
referenced the subcomponent .a files to create the shared library like:
gcc -shared -Wl,-soname,libfoo.so.0.2 src/f1.pic.o src/f2.pic.o \
src/f3.pic.o src/a/pic.a src/b/pic.a -o libfoo.so.0.2.0
But there's one major problem with this. Symbols in the pic.a files can
be excluded in the .so library. However, if the individual subcomponent
..o files are referenced, then they ARE included. But I think it's ugly
for each makefile to have to know all the names of individual .o files
of all subcomponents or sub-subcomponents. Are there compiler options
to get around this problem?
How is this done? Can someone recommend a good method for partitioning
projects into subdirectories?
Thanks,
Mike
| |
| Stephan Brönnimann 2006-02-07, 6:03 pm |
| Michael B Allen wrote:
> I have a project that consists of a few subcomponents. I'm pretty sure
> I want the subcomponents in separate directories with their own Makefile
> so that they are relatively self contained. For example, lets say I have
> a library libfoo with subcomponents a and b, then the file arrangement
> might look like the following:
>
> libfoo-0.2.0/
> Makefile
> src/
> f1.c
> f2.c
> f3.c
> a/
> Makefile
> fa1.c
> fa2.c
> b/
> Makefile
> fb1.c
>
> For a while this was working if each subcomponent directory's Makefile
> created a pic.a archive of PIC object files. The top-level makefile
> referenced the subcomponent .a files to create the shared library like:
>
> gcc -shared -Wl,-soname,libfoo.so.0.2 src/f1.pic.o src/f2.pic.o \
> src/f3.pic.o src/a/pic.a src/b/pic.a -o libfoo.so.0.2.0
>
> But there's one major problem with this. Symbols in the pic.a files can
> be excluded in the .so library. However, if the individual subcomponent
> .o files are referenced, then they ARE included. But I think it's ugly
> for each makefile to have to know all the names of individual .o files
> of all subcomponents or sub-subcomponents. Are there compiler options
> to get around this problem?
The GNU ld option --whole-archive is your friend. I've just played
around with it because the number of object files is getting to large.
Sample target in the makefile:
$(SOLIB): bar.o $(FOOLIB)
$(CXX) -shared -Wl,-soname,$@ \
-Wl,-whole-archive $(FOOLIB) \
-Wl,-no-whole-archive -o $@ $<
> How is this done? Can someone recommend a good method for partitioning
> projects into subdirectories?
Just one golden rule that you must follow: no dependencies between
subdirectories, no dependency of a directory to its parent.
IOW the parent only depends on its childs, all childs are independant.
Free after LAKOS, "J. Large-Scale C++ Software" Design. Addison-Wesley,
1996.
This book is well worth reading.
Regards, Stephan
| |
| Michael B Allen 2006-02-08, 9:06 pm |
| On Tue, 07 Feb 2006 10:59:25 -0800, Stephan Brönnimann wrote:
> Michael B Allen wrote:
>
> The GNU ld option --whole-archive is your friend. I've just played
> around with it because the number of object files is getting to large.
>
> Sample target in the makefile:
> $(SOLIB): bar.o $(FOOLIB)
> $(CXX) -shared -Wl,-soname,$@ \
> -Wl,-whole-archive $(FOOLIB) \
> -Wl,-no-whole-archive -o $@ $<
This is a good option to know about.
I have since found another solution. Rather than reference .a archives
I use a glob pattern for the .o files like:
gcc -shared -Wl,-soname,libfoo.so.0.2 src/f1.pic.o src/f2.pic.o \
src/f3.pic.o src/a/*.pic.o src/b/*.pic.o -o libfoo.so.0.2.0
This is not a purely recursive solution though since the top level
Makefile needs to know about subdirectories of subdirectories. So
if you have a chain of subdirectories a/x/y/z you have to reference
src/a/x/y/z/*.pic.o in the top level Makefile (but at least specific
files aren't referenced in the top level Makefile).
Mike
| |
| Stephan Brönnimann 2006-02-09, 2:55 am |
| Michael B Allen wrote:
> I have since found another solution. Rather than reference .a archives
> I use a glob pattern for the .o files like:
>
> gcc -shared -Wl,-soname,libfoo.so.0.2 src/f1.pic.o src/f2.pic.o \
> src/f3.pic.o src/a/*.pic.o src/b/*.pic.o -o libfoo.so.0.2.0
>
> This is not a purely recursive solution though since the top level
> Makefile needs to know about subdirectories of subdirectories. So
> if you have a chain of subdirectories a/x/y/z you have to reference
> src/a/x/y/z/*.pic.o in the top level Makefile (but at least specific
> files aren't referenced in the top level Makefile).
I see two problems with this approach:
+ The argument list for gcc can get too long:
Then you'll need the GNU ld option --whole-archive.
+ How can one control that all files src/<x>/*pic.o have been created?
Use the .PHONY target and recursive make.
Regards, Stephan
| |
| Michael Zawrotny 2006-02-09, 6:02 pm |
| Stephan Brönnimann <broeni@hotmail.com> wrote:
> Michael B Allen wrote:
>
> I see two problems with this approach:
> + The argument list for gcc can get too long:
> Then you'll need the GNU ld option --whole-archive.
> + How can one control that all files src/<x>/*pic.o have been created?
> Use the .PHONY target and recursive make.
Another possibility (admittedly more drastic considering your existing
infrastructure) would be to read Peter Miller's "Recursive Make
Considered Harmful" (http://aegis.sourceforge.net/auug97.pdf) and
change the whole build philosopy.
Mike
--
Michael Zawrotny
Institute of Molecular Biophysics
Florida State university | email: zawrotny@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069
| |
| phil-news-nospam@ipal.net 2006-03-21, 3:17 am |
| On 9 Feb 2006 15:44:18 GMT Michael Zawrotny <zawrotny@sb.fsu.edu> wrote:
| Stephan Br?nnimann <broeni@hotmail.com> wrote:
|> Michael B Allen wrote:
|> > This is not a purely recursive solution though since the top level
|> > Makefile needs to know about subdirectories of subdirectories. So
|> > if you have a chain of subdirectories a/x/y/z you have to reference
|> > src/a/x/y/z/*.pic.o in the top level Makefile (but at least specific
|> > files aren't referenced in the top level Makefile).
|>
|> I see two problems with this approach:
|> + The argument list for gcc can get too long:
|> Then you'll need the GNU ld option --whole-archive.
|> + How can one control that all files src/<x>/*pic.o have been created?
|> Use the .PHONY target and recursive make.
|
| Another possibility (admittedly more drastic considering your existing
| infrastructure) would be to read Peter Miller's "Recursive Make
| Considered Harmful" (http://aegis.sourceforge.net/auug97.pdf) and
| change the whole build philosopy.
For an example of how I did that (a flattened single Makefile), see my
open source library:
http://libh.slashusr.org/
http://libh.sourceforge.net/
It also does it's building in an empty directory separate from the source
directory which is not modified. Just make a directory, change to it as the
current working directory, and execute the configure script by using a full
path to it. It builds the Makefile in the current directory.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
|
|
|
|
|