[Top][All Lists]

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

Re: Automake and deep directory structure

From: Bob Friesenhahn
Subject: Re: Automake and deep directory structure
Date: Mon, 21 Apr 2014 09:14:24 -0500 (CDT)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

On Mon, 21 Apr 2014, Zé wrote:

From what I've gathered, for this case automake offers essentially two approaches: set the project as a shallow directory structure, where ./src/ is used to list all files in the project, and convert subdirs into convenience libraries[²].

It is not necessary to use a shallow directory structure if all files are listed in one (or the equivalent using include fragments). A bit of extra work is definitely required in order to make sure that things like test scripts work properly (e.g. the test script may need to change to a sub-directory or know how to compute the path to an input file). The benefit is that 'gmake -j' achieves the best build times and unnecessary build actions are minimized. In fact, the primary limiter for compiles becomes the linker since it is the only significant serialized step in the build process. If the compile time for any one source file is kept reasonable, then parallel compiles fly on modern hardware. There becomes a direct correllation between the number of CPU cores available and build time (except for linking!).

The traditional recursive build makes it easy to keep test files/data next to each "component" (and suports 'cd component ; make') but it can result in quite a lot of time being wasted entering/exiting each directory, and quite a lot more time can be spent with linking. Configure times can be much longer since there are more files to substitute in, and the situation becomes much worse if there are subordinate configure scripts. So-called convenience libraries are really just containers of objects and these must be extracted to the individual .o files at link time, resulting in considerable churn and lost time. Since 'make' does not have a complete view of the build dependencies, it is required to do needless actions in order to assure a correct build product.

As there any other options worth mentioning? And what's the recommended option?

The recommended option seems to be a matter of opinion.

I have used the non-recursive build method for two significant projects. Both of them fit your "deep" project description.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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