Please note:The SCons wiki is now restored from the attack in March 2013. All old passwords have been invalidated. Please reset your password if you have an account. If you note missing pages, please report them to webmaster@scons.org. Also, new account creation is currently disabled due to an ongoing spam flood (2013/08/27).
Differences between revisions 3 and 4
Revision 3 as of 2013-08-26 20:08:34
Size: 521
Editor: FannieFel
Comment:
Revision 4 as of 2013-08-28 20:52:25
Size: 4933
Comment: Spam
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
The name of the writer is Tabatha Dexter. Her spouse and children life in North Dakota. What she loves executing is chook [[http://dictionary.reference.com/browse/keeping|keeping]] and now she has time to just take on new factors. http://i874.photobucket.com/albums/ab302/thebestmusclebuildingprograms/tm_daniel.jpg Computer software developing is what she does in her day career but she strategies on switching it. She's been operating on her web page for some time now. Examine it out below: http://musclemaxblog.com = SConfiscation Paradigm =

~+
SConfiscate: ''verb [trans.]'', to convert a (usually foreign) project to use the SCons build system.<<BR>>
SConfiscation: ''noun'', the process of SConfiscating a project.
+~

OK, so I made up the word. It follows in the footsteps of the GNU Autotools people, who speak of "confiscating" a project, meaning that they convert it to their tool chain, that is, make it use {{{automake}}} and {{{autoconf}}} as a precurser to {{{make}}}.

The usual problem is that the maintainers of the project are often reluctant to allow checkins of a new build system until it has been proven. Moreover, some source-code control systems object to foreign files within their tree, so it can be difficult to debug a build system within a live tree that's constantly being updated. This paradigm allows the build system to be isolated from the source (and possibly even distributed independently until the package maintainers see the light and convert).

The SConfisication paradigm uses both {{{Repository}}}() and {{{VariantDir}}}(), so it's an example of how the two functions have complimentary usages. Here's the {{{SConstruct}}} I use as a starting point:

{{{ src = Dir('path').Dir('to').Dir('repository')}}}<<BR>>
{{{ bld = Dir('build')}}}<<BR>>
{{{ dbx = bld.File('.sconsign')}}}

{{{ Repository(src)}}}<<BR>>
{{{ config = SConscript('SConfigure', variant_dir=bld, duplicate=0)}}}<<BR>>
{{{ SConscript('SConscript', variant_dir=bld, duplicate=0, exports='config')}}}<<BR>>
{{{ SConsignFile(dbx.path)}}}

The first three lines are the variable information; they are different for every project. The strange-looking {{{Dir()...}}} sequence is so that the path is platform-independent; there are other was to gain this platform independence, but this technique is simple and straightforward and doesn't require importing Python modules to concatenate the path elements.

The last four lines are pretty much canned and rarely change. I prefer the actual work to be done by two external files: a {{{SConfigure}}} script that is responsible determining the system variability and a {{{SConscript}}} script that creates the build. They communicate through a {{{config}}} object that contains any necessary configuration.

The last line of the {{{SConstruct}}} places the build database within the build tree, so that all knowledge of the build can be eliminated by removing the build directory (''e.g.'', to force a rebuild from scratch). If this is not wanted, the {{{SConsignFile}}}() and the setting of {{{dbx}}} is unnecessary.

For smaller projects, the first {{{SConscript()}}} call, the {{{SConfigure}}} script, and the {{{config}}} object is not needed and can be left out. If the system is extremely small, the external {{{SConscript}}} file can be replaced by a {{{VariantDir}}}() and build declarations within the {{{SConstruct}}}:

{{{ VariantDir(bld, '.', duplicate=0)}}}<<BR>>
{{{ Program(bld.File('prog'), [bld.File('prog1.c'), bld.File('prog2.c')])}}}

However, if the project is this small, it's very unusual that this much machinery is needed.

There are dozens of variants of this paradigm. Here are some examples.

=== Example: Revising an existing SCons-based build system ===

When revamping a build system that already uses SCons, this same pattern can be used to overlay the existing SConscripts with the new ones, and existing ones that don't need to change can still be used in place:

{{{ src = Dir('path').Dir('to').Dir('current')}}}<<BR>>
{{{ bld = Dir('build')}}}<<BR>>
{{{ dbx = bld.File('.sconsign')}}}

''This is a hint: as this page is being composed, the current build system for SCons itself is in sad shape. It was written using a prehistoric version of SCons, before most of the modern conveniences were implemented, and it's a complicated mass of spaghetti. Some serious cleanup is needed, probably pretty much creating a new build system from scratch.''

=== Example: Build system in a subdirectory ===

Some projects support multiple build systems and want the sources for each build system to be kept in a separate subdirectory of the main directory. This paradigm can be easily adapted to do that:

{{{ src = Dir('..').Dir('code')}}}<<BR>>
{{{ bld = Dir('..').Dir('build')}}}<<BR>>
{{{ dbx = bld.File('.sconsign')}}}

This example builds from the '{{{code}}}' subdirectory of the main directory and places the output in the '{{{build}}}' subdirectory of the main directory.

In fact, if the requirement is to exactly replace a build system that builds in the same tree as the source code, it can do that, as well:

{{{ src = Dir('..').Dir('code')}}}<<BR>>
{{{ bld = src}}}<<BR>>
{{{ dbx = File('.sconsign')}}}

In this latter case, we keep the build database in the SCons subdirectory to avoid creating additional artifacts in the source area.

SConfiscation Paradigm

SConfiscate: verb [trans.], to convert a (usually foreign) project to use the SCons build system.
SConfiscation: noun, the process of SConfiscating a project.

OK, so I made up the word. It follows in the footsteps of the GNU Autotools people, who speak of "confiscating" a project, meaning that they convert it to their tool chain, that is, make it use automake and autoconf as a precurser to make.

The usual problem is that the maintainers of the project are often reluctant to allow checkins of a new build system until it has been proven. Moreover, some source-code control systems object to foreign files within their tree, so it can be difficult to debug a build system within a live tree that's constantly being updated. This paradigm allows the build system to be isolated from the source (and possibly even distributed independently until the package maintainers see the light and convert).

The SConfisication paradigm uses both Repository() and VariantDir(), so it's an example of how the two functions have complimentary usages. Here's the SConstruct I use as a starting point:

    src = Dir('path').Dir('to').Dir('repository')
    bld = Dir('build')
    dbx = bld.File('.sconsign')

    Repository(src)
    config = SConscript('SConfigure', variant_dir=bld, duplicate=0)
    SConscript('SConscript', variant_dir=bld, duplicate=0, exports='config')
    SConsignFile(dbx.path)

The first three lines are the variable information; they are different for every project. The strange-looking Dir()... sequence is so that the path is platform-independent; there are other was to gain this platform independence, but this technique is simple and straightforward and doesn't require importing Python modules to concatenate the path elements.

The last four lines are pretty much canned and rarely change. I prefer the actual work to be done by two external files: a SConfigure script that is responsible determining the system variability and a SConscript script that creates the build. They communicate through a config object that contains any necessary configuration.

The last line of the SConstruct places the build database within the build tree, so that all knowledge of the build can be eliminated by removing the build directory (e.g., to force a rebuild from scratch). If this is not wanted, the SConsignFile() and the setting of dbx is unnecessary.

For smaller projects, the first SConscript() call, the SConfigure script, and the config object is not needed and can be left out. If the system is extremely small, the external SConscript file can be replaced by a VariantDir() and build declarations within the SConstruct:

    VariantDir(bld, '.', duplicate=0)
    Program(bld.File('prog'), [bld.File('prog1.c'), bld.File('prog2.c')])

However, if the project is this small, it's very unusual that this much machinery is needed.

There are dozens of variants of this paradigm. Here are some examples.

Example: Revising an existing SCons-based build system

When revamping a build system that already uses SCons, this same pattern can be used to overlay the existing SConscripts with the new ones, and existing ones that don't need to change can still be used in place:

    src = Dir('path').Dir('to').Dir('current')
    bld = Dir('build')
    dbx = bld.File('.sconsign')

This is a hint: as this page is being composed, the current build system for SCons itself is in sad shape. It was written using a prehistoric version of SCons, before most of the modern conveniences were implemented, and it's a complicated mass of spaghetti. Some serious cleanup is needed, probably pretty much creating a new build system from scratch.

Example: Build system in a subdirectory

Some projects support multiple build systems and want the sources for each build system to be kept in a separate subdirectory of the main directory. This paradigm can be easily adapted to do that:

    src = Dir('..').Dir('code')
    bld = Dir('..').Dir('build')
    dbx = bld.File('.sconsign')

This example builds from the 'code' subdirectory of the main directory and places the output in the 'build' subdirectory of the main directory.

In fact, if the requirement is to exactly replace a build system that builds in the same tree as the source code, it can do that, as well:

    src = Dir('..').Dir('code')
    bld = src
    dbx = File('.sconsign')

In this latter case, we keep the build database in the SCons subdirectory to avoid creating additional artifacts in the source area.

SConfiscation (last edited 2013-08-28 20:52:25 by WilliamDeegan)