Re: [Opensg-core] Plans for SCons Build System

[Dirk R. <dre...@ia...>]

	Hi Chad,

On Sat, 2004-01-17 at 21:38, Chad Austin wrote:
> 
> Right after responding to Gerrit's message above, I realized that it does help 
> in terms of setting up correct dependencies when generating source code as part 
> of the build.  Right now, I'm building everything within the source tree.  Once 
> I get that working, it's trivial to add support for build directories.  SCons' 
> BuildDir support makes a virtual mirror of the source tree (copying/linking 
> source files over or not) and the build actually occurs within the build tree.

just to make sure i understand it, you can use SCons without copying
over source files, essentially the way we have it right now? Given the
size of the system that would an overhead that I would like ot avoid.

> Normally, this wouldn't be much of an issue.  But when you're searching on the 
> filesystem for files, you might not find anything (if it's a build dir or you 
> are building from a repository using the -Y option), or you might not find files 
> you want (if OSGScanParseSkel hasn't been generated yet).

Hmm, good point. These files need some unaesthetic special cases, so
getting rid of that would be nice. But you would still have to special
case some things that are not generated by standard build rules like the
bug-fixed flex header.

> It's important to realize that SCons has two phases:  SConscript-read time, and 
> build time.  When reading SConscripts, environments, actions, and the dependency 
> tree itself is set up.  By the time building starts, all dependencies are known; 
> this is one reason scons -j is so awesome.

How does SCons detect dependencies anyway? Does it use something like
makedepend, i.e. its own preprocessor? I understand it does not use time
stamps to notify changes, but an MD5 hash instead. Is that done every
time a build is run, or only when timestamps are different? MD5ing the
whole for every build sounds expensive...

> Now, in the case of OSGScanParseSkel...  That source has to always be listed 
> explicitly, because it may or may not be found with a glob.  It just seems to be 
> inconsistent to list generated files, but not normal source files.

There would probably still be a bunch of special cases, for building
files, so that wouldn't totally clean it out. It would be nice if we
could put the actual rules for these special cases in the directories
where they are generated, to make things a little more decentralized.

> Along the same lines, you could even build source code from the FCD files as 
> part of the build process (dunno how useful that is), but you'd almost certainly 
> need explicit source listings then.

I know Andreas does this for his system. In general I would like it, but
I would still put the sources into the repository. Not everybody has a
running fcdEdit.

> What's common.libs.in?  Could someone explain it to me?

See below.

On Sat, 2004-01-17 at 21:43, Chad Austin wrote: 
> 
> Okay, I'm confused by this part.  Do you dynamically build the list of source 
> directories too?

Yes and no. At configure time we collect common.libs.in files (no idea why they're 
called that, it's a leftover from Gerrit's scheme ;). These are pretty simple shell 
scripts that can add to the list of libraries and can also add directories to 
existing library configurations. So to add stuff to the system you just drop the 
directory in the source tree, reconfigure and recompile. That's pretty useful for 
people to add stuff like Contrib components.With a dynamic library loader that wouldn't
be as much of an issue as it is now, but it's still useful.

	Dirk