Hello
I'm working on a C++ project on linux and I want to use autotools.
Before that I need to change the organization of the projects.

For the moment, this is how it is organized:

bin for binaries
DEV/Makefile : a makefile for all the project
DEV/SOC/src => source code for socket classes
DEV/SOC/include => headers of socket classes
DEV/SOC/obj => .o files

DEV/DRI/src => .cc class for drivers
DEV/DRI/include => headers of drivers
DEV/DRI/obj => .o

and so on

DEV/LIB => libraries needed by the project

On open-sources project, I see :
src/
and then directory for each package:
src/socket (in this case) where you have ".cc",  ".h" and ".o"

Is there rules for the source code organization?

With autotools I need to put a Makefile.am in each directory that's
why I want to reorganize everything.

Any ideas will help me.

Thanks

lhommedumatch wrote:
> I'm working on a C++ project on linux and I want to use autotools.

Whatever.  Off-topic here anyway.

> Before that I need to change the organization of the projects.

If you say so.

> For the moment, this is how it is organized:
> 
> bin for binaries
> DEV/Makefile : a makefile for all the project
> DEV/SOC/src => source code for socket classes
> DEV/SOC/include => headers of socket classes
> DEV/SOC/obj => .o files
> 
> DEV/DRI/src => .cc class for drivers
> DEV/DRI/include => headers of drivers
> DEV/DRI/obj => .o
> 
> and so on
> 
> DEV/LIB => libraries needed by the project
> 
> On open-sources project, I see :
> src/
> and then directory for each package:
> src/socket (in this case) where you have ".cc",  ".h" and ".o"
> 
> Is there rules for the source code organization?

No.

> With autotools I need to put a Makefile.am in each directory that's
> why I want to reorganize everything.

OK.

> Any ideas will help me.

Get a copy of "Large Scale C++ Software Design" by Lakos.  Outdated in 
some areas, it still contains enough wisdom (about how to organise your 
projects as well) to warrant having it in one's library.

V
-- 
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

lhommedumatch wrote:

> With autotools I need to put a Makefile.am in each directory that's
> why I want to reorganize everything.

autotools have an alias called autohell because it is too complex like in 
hell. As a developer I can't understand how it works. I now prefer strongly 
on cmake.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksnWPEACgkQG6NzcAXitM8kRgCdEv6ooxdq82S8erJPKiZe5Kse
WdUAnRj8AGfmfzeFl9EYAWKVm8kYYogA
=gqs9
-----END PGP SIGNATURE-----

Thanks,
I think I will use cmake

On 14/12/09 19:54, lhommedumatch wrote:
> Hello
> I'm working on a C++ project on linux and I want to use autotools.
> Before that I need to change the organization of the projects.

I would suggest using plain GNU make for simplicity if you build for a 
limited set of platforms.

> For the moment, this is how it is organized:
>
> bin for binaries
> DEV/Makefile : a makefile for all the project
> DEV/SOC/src =>  source code for socket classes
> DEV/SOC/include =>  headers of socket classes
> DEV/SOC/obj =>  .o files
>
> DEV/DRI/src =>  .cc class for drivers
> DEV/DRI/include =>  headers of drivers
> DEV/DRI/obj =>  .o
>
> and so on

Where to put object and binary files depends on the requirements of your 
project. For example, if you'd like to switch between debug and release 
mode builds often it makes sense to add the build mode name in the name 
of the folder for object and binary files, e.g. obg-debug and obj-debug. 
This way when you switch between the build modes make does not confuse 
debug object files with the release ones. Same for the static and shared 
libraries and executables.

It is also very convenient to put the generated dependency .d files into 
the corresponding object file folder along with the corresponding .o 
because debug and release build header dependencies may well be different.

The most flexible way is to build into a separate build root folder. 
Under that root folder the source folder tree is replicated (source 
files don't get replicated and stay where they are). For example, 
${src_dir}/SOC/src/socket.cc gets compiled into 
${root_dir}/obj/SOC/src/socket.o and ${root_dir}/obj/SOC/src/socket.d. 
Shared libraries and executable binaries go under ${root_dir}/bin.

As a part of its name the root folder may include the build mode and, 
for multi-platform/architecture builds, it may also include platform 
(say Linux, SunOS, etc..), architecture (i686, x86_64, etc..), memory 
model (32/64 bit), compiler name (gcc, icc, etc..) and compiler versions 
if you intend to build often with different compilers, and the build 
model. For example: Linux.x86_64.64.gcc-4.4.debug. You can figure all 
this information from within the makefile ($(shell uname), $(shell gcc 
--version)) and construct the root build folder name.

-- 
Max

On 2009-12-14, lhommedumatch <ludocluba@yahoo.com> wrote:
> Hello
> I'm working on a C++ project on linux and I want to use autotools.
> Before that I need to change the organization of the projects.
>
> For the moment, this is how it is organized:
>
> bin for binaries

An Autotools project should be able to build in a separate build
directory.

$ mkdir build_the_project
$ cd build_the_project
build_the_project $ /path/to/project/configure
build_the_project $ make ; make install

There can be a bin directory, but it's relative to the build
directory, not to the original source directory.

> With autotools I need to put a Makefile.am in each directory that's

Google for "Recursive Make Considered Harmful" and read the paper.
Two or three times, if necessary.

I don't believe that autotools /requires/ this; it may be a dumb
way of using Autotools that many projects are following.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

lhommedumatch wrote:

> Thanks,
> I think I will use cmake

If portability is not your concern, you may just use plain GNU make, 
otherwise, use cmake is better.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksoapgACgkQG6NzcAXitM9UlACeKTv7JVVxdSRo6Z8IOMNVvhm6
Uy4AmgIwjDs1IFh6AIl8feTRfPUEOH5F
=6bdl
-----END PGP SIGNATURE-----

Michael Tsang wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> lhommedumatch wrote:
> 
>> Thanks,
>> I think I will use cmake
> 
> If portability is not your concern, you may just use plain GNU make, 
> otherwise, use cmake is better.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iEYEARECAAYFAksoapgACgkQG6NzcAXitM9UlACeKTv7JVVxdSRo6Z8IOMNVvhm6
> Uy4AmgIwjDs1IFh6AIl8feTRfPUEOH5F
> =6bdl
> -----END PGP SIGNATURE-----
> 
Please stop posting with all that PGP nonsense, it's very annoying on 
Usenet.

-- 
Ian Collins

On 16 d=E9c, 02:15, Kaz Kylheku <kkylh...@gmail.com> wrote:
> On 2009-12-14, lhommedumatch <ludocl...@yahoo.com> wrote:
[snip]
> Google for "Recursive Make Considered Harmful" and read the paper.
> Two or three times, if necessary.
> I don't believe that autotools /requires/ this; it may be a dumb
> way of using Autotools that many projects are following.

It doesn't create a Makefile per directory but requires a
configuration Makefile.am per directory. And in a Makefile.am
directories are not allowed in source definition.

Perhaps you could read the autotools manual once :)

--
Michael