Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

source code organization in a C++ project

9 views
Skip to first unread message

lhommedumatch

unread,
Dec 14, 2009, 2:54:35 PM12/14/09
to
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

unread,
Dec 14, 2009, 3:41:21 PM12/14/09
to
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

Michael Tsang

unread,
Dec 15, 2009, 4:37:53 AM12/15/09
to
-----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-----

lhommedumatch

unread,
Dec 15, 2009, 4:17:51 PM12/15/09
to
Thanks,
I think I will use cmake

Maxim Yegorushkin

unread,
Dec 15, 2009, 7:18:20 PM12/15/09
to
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

Kaz Kylheku

unread,
Dec 15, 2009, 8:15:19 PM12/15/09
to
On 2009-12-14, lhommedumatch <ludo...@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.

Michael Tsang

unread,
Dec 16, 2009, 12:05:28 AM12/16/09
to
-----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-----

Ian Collins

unread,
Dec 16, 2009, 12:37:55 AM12/16/09
to
Please stop posting with all that PGP nonsense, it's very annoying on
Usenet.

--
Ian Collins

Michael Doubez

unread,
Dec 16, 2009, 7:19:45 AM12/16/09
to
On 16 déc, 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

0 new messages