[Christian Goetze <cg@resolute.com>] First benchmarks for non-recursive build...

[Ulrich Drepper <drepper@cygnus.com>]

Might be interesting to keep in mind for the makefile rewrite.

I, for example, recompile on specific directories when I change
something.  A rewrite would have to allow this as well.
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

---

• To: cook-users@canb.auug.org.au
• Subject: First benchmarks for non-recursive build...
• From: Christian Goetze <cg@resolute.com>
• Date: Thu, 10 Dec 1998 12:55:15 -0800 (PST)
• cc: Dennis Blay <blayde@resolute.com>

I'm in the process of redesigning my current recursive build system to a
non-recursive one similar to the one recommended in the cook user's guide.

I have finished the manifest generation and the header dependency parts.
On a sparc 2 dual processor machine with 256MB of memory and a disc array,
operating on a project with approc. 7,800 source files, it takes about 90
seconds for the system to realize that everything is up to date.

This is of course a lot faster than my recursive build system would take
for a whole system build, but it is a lot slower than a typical
developer-invocation of my old recursive system, which is about 1-2
seconds inside the average directory.

In practise, I fear that even though the actual build times might average
out favorably for the non-recursive system, the _impression_ will be of a
very slow system, since every invocation will at least take 90 seconds.

I'm not sure if there is a good solution to this except a lot of
education... I'm still not sure if some segmentation wouldn't make sense,
maybe not at the library level but perhaps at a subsystem level...

For now, I will continue down this route and see how the actual compiling
and linking will fare - I fear it will add another 10-15 seconds to the
basic overhead...

One nice thing is that using c_incl instead of a perl script is a huge
gain, in particular in combination with the cascade recipes...

Has anyone already patched c_incl to support java's import lines? Even
though the javac is a whole build system in itself, it is still necessary
to know that you need to invoke it _somewhere_ in the first place...
--
cg



To unsubscribe from this list: send the line "unsubscribe cook-users" in
the body of a message to majordomo@canb.auug.org.au

---