Re: autoconf help?

[Pierre Phaneuf <pphaneuf@sx.nec.com>]

Christian Reiniger wrote:

> This in itself isn't bad, but the real point (on which also his entire
> argumentation is based) is that parse.h is included by (obviously) parse.c
> *and* by main.c
> In this situation the above directory layout is complete crap. Something
> like this would solve the problem:
> 
> Project/
>   Makefile
>   include/
>     Makefile
>     parse.h
>   module1/
>     Makefile
>     main.c
>   module2/
>     Makefile
>     parse.c
> 
> Although this layout is "bigger" than the first one, it imposes a good deal
> less problems on the build system, simply because all headers that are
> needed by more than 1 module are in a central place.
> 
> This also explains why I didn't see any speed problems (regarding "make"
> that is) with the LibPenguinPlay build system, which has the following dir
> layout (simplified):
> 
> include/
>   Makefile
>   header1.h
>   ...
> src/
>   Makefile
>   utility1.cpp
>   ...
>   PenguinFile/
>     Makefile
>     pfsource1.cpp
>     ...
>   PenguinSound/
>     Makefile
>     pssource1.cpp
>     ...
>   tests/
>     Makefile
>     testsrc1.cpp
>     ...

It would still help. You have any idea of the number of times that
header1.h was stat()ed?

Also, the fact that 'make' is an expert system also means that it needs
to know as much as possible about the project at hand. Fragmenting the
knowledge among separate 'make' invocations is counter to that. For
example, if you have a tests/testsound subdirectory and you change a
pfsource1.cpp, 'make' will have to go in tests/testsound, parse the
Makefile, stat() a bunch of file, only to determine that there is
nothing to do and exit. Do that a few hundred time, and this is starting
to take a while. Add the unneeded parsing time of 'make' invocations
that actually do something, and you have a huge amount of time (for such
a tool as make).

Note that I didn't say "fragmenting the knowledge among separate
Makefiles", but rather "'make' invocations". I use separate makefiles,
but they are not called "Makefile" (so a raw 'make' in a subdirectory
doesn't give you weird stuff), they simply are included from the top
level one. For example:

include $(wildcard */rules.mk)

Non-recursive makefiles *do* require a bit more experience to create
correctly (if only automake could do this for us). For example, I
learned from previous experience that it is much better to define rules
and variables separately, either in two different files that you include
(I do that) or in a single file with a variable that say what you want
(checked with a "if" in each sub-makefiles), including the sub-makefiles
two times.

-- 
Pierre Phaneuf
Systems Exorcist

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk