source code organization in a C++ project

[lhommedumatch]

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

 

[Victor Bazarov]

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

 

[Michael Tsang]

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

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

 

[lhommedumatch]

Thanks,
I think I will use cmake

 

[Maxim Yegorushkin]

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.

 

[Kaz Kylheku]

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.

 

[Michael Tsang]

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

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

 

[Ian Collins]

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


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.

 

[Michael Doubez]

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