No subject


Wed Dec 14 07:05:40 CET 2011


of the time. This isn't harmless. This is a Broken Window.

== disagreement on methodical goals

On a second thought, for me this issue highlights a more subtle discord
about what actually is desirable. IMHO *that* is something we really need
to address and resolve. We seem to go for different goals here.

The Autotools build seems to be defined deliberately manual and explicit.
Each file is mentioned explicitly, each file requires one explicit manual
step to add it to the build, and compile / link flags and depencencies
seem to be specified deliberately manual.

I think such would be appropriate for a small project, but is the wrong
approach for a large project. We're getting close to 1000 files now, and
this number will increase significantly. Plus there will be plug-ins,
metadata and interfaces and resources. Rather, we should strive at reducing
complexity by abstracting things. Instead of looking at 1000++ files,
we should look at 5 modules or so. Instead of building each test
a little bit different, we should distil a common pattern for all tests.
We need to strive at a systematic approach, because we really need to
focus ourselves at our primary goal.

Similarly, IMHO there is no point in looking at library dependencies
with ldd or changing linker flags. Because we *do* have a problem with
the *concept* of our Lumiera interface library. And the reason is,
that we're not ready to define an external interface for scripted
use of Lumiera. Our design simply isn't mature enough for that.
First things first -- which IMHO means continuing to target
the design and implementation of a complete render pipeline.


= Assessment of the Autotools build

After having listed all those deficiencies of Autotools, I should
add that under certain circumstances, using Autotools does yield a
significant benefit, which might outweigh the costs. But I don't
even remotely see Lumiera to be in that situation. Frankly, I
see zero benefit from using Autotools for us.


= Assessment of the SCons build

The results on the SCons buildsysem are also not entirely favourable,
but overall I see far less serious problems. Yet still, we should
noteice and try to judge benefits and problems here as well.

== benefits

- the SCons build definition is actually declarative. "What" instead of "how".
- using Python as the definition language avoids problems with language design.
  It does have its quirks, but its expressiveness is beyond any doubt.
- Python has the necessary language constructs to support a clean coding style.
- the concept of a "build environment" helps with reducing the build into a
  small number of standard situations plus a local variation here and there.
- SCons deliberately sanitises the build environment and isolates the build
  from external influences. The build "sees" exactly those libraries you
  pick up beforehand, and it effectively prevents any environment variables
  to "sneak in" and influence the build behind the scenes.
- SCons is actually based on a design chosen to reflect the reality of
  the build process. Changes are detected based on actual file content (MD5)
  plus understanding the dependencies (parsing headers). Additionally, SCons
  tracks the effect of changed compiler flags and detects changes in library
  versions due to system upgrade.

== issues

Out of the box, SCons is relatively low-level. It lacks some of the ready-made
solutions we know from Autotools. Basically, SCons is more like a sophisticated
Make; it's rather just a build tool, not a build system.

Thus, each SCons based build system is more or less "custom". For example,
I've written a LumieraEnvironment (sub)class, which embodies project specific
knowledge how to link and how to build Lumiera plug-ins. (This idea is
thanks to the build system of Ardour)

There is no predefined support for libraries at non standard locations.
SCons either relies on the toolchain, or you have to add an commandline
option explicitly and feed that manually to the build environment.

The support for building in a separate build directory is somewhat strange
and just differs from what Autotools does. For now we build in-tree

SCons is known to be slow (it's Python, after all). Benchmarks indicate that
it might degenerate with 20000 or 40000 files. (but stock Autotools similarly
degenerates on such large projects)

Prior to SCons 1.0, we had some compatibility problems









More information about the Lumiera mailing list