automake
[Top][All Lists]
Advanced

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

Re: Adapting existing directory structure to autotools


From: Ralf Wildenhues
Subject: Re: Adapting existing directory structure to autotools
Date: Fri, 11 Sep 2009 20:40:03 +0200
User-agent: Mutt/1.5.20 (2009-08-09)

Hello Kenneth,

* Kenneth Porter wrote on Thu, Sep 10, 2009 at 09:40:22PM CEST:
> I'm porting a proprietary Windows DLL and demo app to Linux and I'm
> trying to figure out the best way to structure the build system. I'm
> trying to figure out how to use autoconf, automake, and libtool and
> whether I need to restructure my project.

First I'd try to get acquainted with the concept of source, build, and
install trees, and some other concepts,
<http://www.gnu.org/software/automake/manual/html_node/Autotools-Introduction.html>.

Then it's helpful to know what recursive and what nonrecursive build is,
<http://www.gnu.org/software/automake/manual/html_node/Alternative.html>.

> My existing directory structure is like this:
> 
> include/MyLibrary/*.h   // public headers
> src/MyLibrary/*.{cpp,h} // DLL sources
> src/MyApp/*.{cpp,h}     demo application
> src/Vendor/lib1/*.{cpp,h} // my vendor's first library
> src/Vendor/lib2/*.{cpp,h} // my vendor's second library, depends on 1st
> src/Vendor/include/*.h    // target where vendor's public headers get
>                        //copied
> lib/*.dll               // for Windows, where the DLL and app gets
>                        // installed before packaging
> 
> I statically link the DLL to the vendor's libraries. My top-level
> build file (a Windows "solution") is in the demo app directory, so
> that I can build the app, the DLL, and everything they depend on with
> one button.
> 
> When I package under Windows, I just grab everything in the include
> and lib top-level directories.
> 
> What's the best way to integrate this scheme into a Linux build? Will
> I need to shuffle all the directories around into a hierarchy? Can I
> get something equivalent with clever use of symbolic links?

I don't think you need to use symbolic links.  One thing I'd change is
to build the libraries in the build tree directory that corresponds to
the source tree directory in which their source files are.

With a standard recursive build you can just have a Makefile.am file in
each directory which contains sources.  For example:

--- toplevel Makefile.am:
SUBDIRS = include src

--- include/Makefile.am:
# if those headers are to be installed in $includedir/include/*.h:
nobase_include_HEADERS = MyLibrary/foo.h ...

--- src/Makefile.am:
# order of subdirs is imortant here!
SUBDIRS = Vendor MyLibrary MyApp

# or even this (and then omit src/Vendor/Makefile.am):
SUBDIRS = Vendor/lib1 Vendor/lib2 Vendor/include MyLibrary MyApp

--- src/MyLibrary/Makefile.am:
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.cpp foo.h ...
# my lib depend on the vendor libs:
libfoo_la_LIBADD = ../Vendor/lib2/libvendor.la

--- src/MyApp/Makefile.am:
bin_PROGRAMS = demo
demo_SOURCES = demo.cpp demo.h ...
demo_LDADD = ../MyLibrary/libfoo.la ...


For each Makefile.am, you need to list the respective Makefile in an
AC_CONFIG_FILES statement in configure.ac, and you'll need the other
standard blurb stuff there, too, of course.

Hope that helps.

Cheers,
Ralf




reply via email to

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