Re: project in multiply directories

[Steffen Dettmer]

On Sun, Sep 27, 2009 at 11:45 PM <address@hidden> wrote:
> Good Day, dear GNU community :-)
>
>-------------------------------------------------------
> .
> |-- Makefile.am
> |-- base
> |   |-- Makefile.am
> |   |-- 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 Makefile.am in top
level with all the rules (all libs etc). By this, make can show
its strengths best. Often, a Makefile.am "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 Makefile.am "per component" could be a compromise, as you
drafted it in your structure (base/Makefile.am).

>    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/Makefile.am write things like
  if HAVE_SDL
  libLIBRARIES=libmylibsdl.a
  libmylibsdl_a_SOURCES=lib/sdl/mylib_sdl.h lib/sdl/mylib_sdl.cc
  mylibsdlincludedir=$(prefix)/sdl
  mylibsdlinclude_HEADERS=lib/sdl/mylib_sdl.h
  endif
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
ENABLE_MYLIBSDL I think.
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.

oki,

Steffen