[Top][All Lists]

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

Re: project in multiply directories

From: Steffen Dettmer
Subject: Re: project in multiply directories
Date: Mon, 28 Sep 2009 12:13:26 +0200

On Sun, Sep 27, 2009 at 11:45 PM <address@hidden> wrote:
> Good Day, dear GNU community :-)
> .
> |--
> |-- base
> |   |--
> |   |-- err
> |   |   |-- err.cpp
> |   |   `-- err.h
> |   |-- io_base.cpp
> |   |-- io_base.h
> |-- graphic
> |   |-- grp_base.h
> |   |-- grp_color.h
> |   `-- lib
> |       `-- sdl
> |           |-- sdl_base.cpp
> |           |-- sdl_base.h
> ------------------------------------------------------------
> i am triing to produce such functionality:
> 1) source file from one subdirectory can include source file
>    from another directory.

I think this is an automake question.

I'm don't know well about autoconf/automake but I reply
nevertheless; I hope someone of the gurus corrects the biggest
errors that I wrote.

When you build more that a single lib file, you have to be
careful to avoid cyclic dependencies. Althrough you can link even
then (with "-Wl,-(" and "-Wl,-)" linker options IIRC), but
usually problems happen later.

There is an article called "recursive make considered harmful".
According to it, you should have just one in top
level with all the rules (all libs etc). By this, make can show
its strengths best. Often, a "per directory" seems
to be used, but for a new project today this should be avoided.
It just slows things down and leads to unneeded compiler calls.

On disadvantage, IMHO, is that by this someone probably ends up
with too long include paths.

In your project that would mean that base/err/err.h could include
sdl_base.h which surely would not be intended (but compiler would
accept this).

One "per component" could be a compromise, as you
drafted it in your structure (base/

>    For example, source file from
>    base/err/err.cpp can include "utils/ascii_window.h" or
>    include "ascii_window.h" (maybe second variant is better?)

For me it the second variant is really bad - in the company where
I work we even have development rules that forbid that, it must
be included with directory, such as #include "base/err/err.h",
which, BTW, probably is not a good name :-). BTW, if you have
some code /using/ SDL, I think it should not be called sdl_base
or so (sdl_base IMHO would suggest it would be file of SDL
itself). If you define MYLIB for instance I think it could be
called MBLIB_sdlwrap.h or so or just MYLIB because it is in a
subdirectory ./sdl/ (which could be mylib_sdl of course :)).

> 2) all source files will be compile from all subdirectories

What does this mean?
To build it, usually you run make in highest directory and each
file just builds in one subdirectory.

> 3) allow turn off compilation of some subdirectory. For example
> - user haven't installed lib sdl, but he have another supported
> lib (like OpenGL). In makefile i must have some flag like
> "enable of compilation of lib/sdl sources"

You could use AM_CONDITIONAL and in graphic/ write things like
  libmylibsdl_a_SOURCES=lib/sdl/mylib_sdl.h lib/sdl/
as far as I know this works with newer automake. When testing, I
strongly recommend to frequently use "make distcheck". This is
really helpful. Instead of HAVE_SDL better would be if
Some think it is better to compile all files always and thus use
#if in the .cc files. Probably a matter of taste.

> 4) object from lib/sdl must be compiled as shared lib, and linked with main
> source file good.cpp

You want to build a shared lib? I think then libtool may be worth
a look. You need wrappers to even run a unit test then!
So why not simply link statically.



reply via email to

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