project in multiply directories

[Feniks Gordon Freeman]

Good Day, dear GNU community :-)

I can't find a solution for my problem. I have project on C++ language. All
sources in project stored in a directories. I am triing to write Makefile.am
and configure.ac files. Here is project struct:

------------------------------------------------------------------------------------
.                                                                                                                                                            
|-- Makefile                                                                                                                                                
|-- Makefile.am                                                                                                                                              
|-- Makefile.in                                                                                                                                              
|-- audio                                                                                                                                                    
|-- base                                                                                                                                                    
|   |-- Makefile.am                                                                                                                                          
|   |-- err                                                                                                                                                  
|   |   |-- err.cpp                                                                                                                                          
|   |   `-- err.h                                                                                                                                            
|   |-- io_base.cpp                                                                                                                                          
|   |-- io_base.h                                                                                                                                            
|   |-- io_buf.h
|   |-- io_rc.cpp
|   `-- io_rc.h
|-- files
|-- game_base
|   |-- game_main.cpp
|   `-- game_main.h
|-- good.cpp
|-- graphic
|   |-- grp_base.h
|   |-- grp_color.h
|   |-- grp_coord.cpp
|   |-- grp_coord.h
|   |-- grp_line_cda.h
|   |-- grp_rect.h
|   `-- lib
|       `-- sdl
|           |-- sdl_base.cpp
|           |-- sdl_base.h
|           |-- sdl_image.cpp
|           |-- sdl_image.h
|           |-- sdl_screen.cpp
|           |-- sdl_screen.h
|           |-- sdl_surface.cpp
|           |-- sdl_surface.h
|           `-- sdl_utils.h
|-- io
|   `-- files
|-- math
|   `-- mth_utils.h
|-- network
|   `-- socks
|-- rc
`-- utils
    `-- text
        |-- ascii_window.cpp
        |-- ascii_window.h
        |-- regexp.cpp
        `-- regexp.h

------------------------------------------------------------------------------------

i am triing to produce such functionality:
1) source file from one subdirectory can include source file from another
directory. 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?)
2) all source files will be compile from all subdirectories
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"
4) object from lib/sdl must be compiled as shared lib, and linked with main
source file good.cpp

I am realy crazy, i can't find any solution :-) . If you have some idea or
solution, please, help me.

With best wishes, Maxim Sditanov



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Alberto Luaces]

Hello Maxim,

I recommend you to read the tutorial at
http://www.lrde.epita.fr/~adl/autotools.html . It addresses all of your
questions. See below:

> i am triing to produce such functionality:
> 1) source file from one subdirectory can include source file from another
> directory. 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?)

You can refer to any subdirectory in the source with
$(srcdir)/your_subdirectory. For including purposes you'd use -
I$(srcdir)/directory.

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

You can put full paths to these files in your Makefile.am or create one
Makefile.am for every subdirectory and refer each file by its name. See
SUBDIRS in the tutorial.

> 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"

This is covered on page 92 of the tutorial, "Conditinals: usage"

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

You can link with system libraries or with libraries created in your own
project.

Alberto



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Sun, Sep 27, 2009 at 11:45 PM <feniksgordonfreeman@...> 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


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Alfred M. Szmidt]

   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.

I'm sorry, but where on earth did you get this terrible information?

A Makefile.am per directory is precisly what should be used, it
doesn't incure any extra compiler calls.  It also makes it easy to
build seperate parts of the tree.

   [...] Instead of HAVE_SDL better would be if ENABLE_MYLIBSDL I
   think.

Please don't.  `Enable' means to enable a feature, linking to a
library is not a feature.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Allan Clark-3]

On Sep 28, 2009, at 12:04, "Alfred M. Szmidt" <ams@...> wrote:

>   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.
>
> I'm sorry, but where on earth did you get this terrible information?
>
> A Makefile.am per directory is precisly what should be used, it
> doesn't incure any extra compiler calls.  It also makes it easy to
> build seperate parts of the tree.

There is an existing paper about this argument. This is exactly  
addressed in the automake documentation, and automake supports that  
single-directory method if you so choose. I can find the reference for  
you in a few hours.

I do note that this is the autoconf list, not automake. I don't see a  
crosspost.

Allan


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Alfred M. Szmidt]

   >   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.
   >
   > I'm sorry, but where on earth did you get this terrible
   > information?
   >
   > A Makefile.am per directory is precisly what should be used, it
   > doesn't incure any extra compiler calls.  It also makes it easy
   > to build seperate parts of the tree.

   There is an existing paper about this argument. This is exactly
   addressed in the automake documentation, and automake supports that
   single-directory method if you so choose. I can find the reference
   for you in a few hours.

I was not addressing Peter Millers paper, which is an excellent read.
What was being addressed was your claim that a Makefile.am per
directory should be avoided, which is simply not true.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

On Mon, 28 Sep 2009, Alfred M. Szmidt wrote:

>   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.
>
> I'm sorry, but where on earth did you get this terrible information?
>
> A Makefile.am per directory is precisly what should be used, it
> doesn't incure any extra compiler calls.  It also makes it easy to
> build seperate parts of the tree.

The main advantage of a Makefile per directory is that it makes it
easier to request building seperate parts of the tree.  Otherwise the
approach can waste quite a lot of build performance since each
sub-make must stat(2) all off the files required by the Makefile
target as well as all of the generated source file dependencies, and
there is quite a lot of redundant processing (e.g re-linking) which
does not need to occur.  A non-recursive build can help avoid
depending on archive libraries and "convenience" libraries which often
consume quite a bit of the build time.

I have taken a number of large Automake-based projects (C and C++) to
non-recursive builds and have not regretted it.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Corsepius]

On 09/28/2009 05:55 PM, Bob Friesenhahn wrote:
> On Mon, 28 Sep 2009, Alfred M. Szmidt wrote:
>
>> There is an article called "recursive make considered harmful".
IMO, one of the most overrated articles of all times.

>> 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.
>>
>> I'm sorry, but where on earth did you get this terrible information?
>>
>> A Makefile.am per directory is precisly what should be used, it
>> doesn't incure any extra compiler calls. It also makes it easy to
>> build seperate parts of the tree.
>
> The main advantage of a Makefile per directory is that it makes it
> easier to request building seperate parts of the tree.

Right. Exactly this is a huge win in bigger projects.

> Otherwise the
> approach can waste quite a lot of build performance since each sub-make
> must stat(2) all off the files required by the Makefile target as well
> as all of the generated source file dependencies, and there is quite a
> lot of redundant processing (e.g re-linking) which does not need to
> occur. A non-recursive build can help avoid depending on archive
> libraries and "convenience" libraries which often consume quite a bit of
> the build time.
Agreed, ... but the keyword is "can".

> I have taken a number of large Automake-based projects (C and C++) to
> non-recursive builds and have not regretted it.
I did the same and occasionally regret it. It's as in most situations:
Everything comes at a price and all approaches have their use-cases.

Ralf



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

On Mon, 28 Sep 2009, Ralf Corsepius wrote:
>>
>> The main advantage of a Makefile per directory is that it makes it
>> easier to request building seperate parts of the tree.
> Right. Exactly this is a huge win in bigger projects.

Not necessarily.  Even with some smaller projects (e.g. libtiff) I
usually see that the costs incurred by the recursion are greater than
the build costs.  In large recursive projects, it is common for many
unnecessary things to be done after editing one source file and typing
'make', which encourages building in a subdirectory.  In a
non-recursive build it is still possible to build any individual
component by specifying 'make path/to/target'.  If the incantation is
too difficult to remember (or takes too much typing) then just add an
alias target name for it.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf