Introduction to s cons
Upcoming SlideShare
Loading in...5

Introduction to s cons






Views auf SlideShare
Views einbetten


Gefällt mir

5 Einbettungen 3,614 3580 27 5 1 1



Details hochladen

Uploaded via as Microsoft PowerPoint


© Alle Rechte vorbehalten

Report content

Als unangemessen gemeldet Als unangemessen melden
Als unangemessen melden

Wählen Sie Ihren Grund, warum Sie diese Präsentation als unangemessen melden.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Ihre Nachricht erscheint hier
Kommentar posten
Kommentar bearbeiten

    Introduction to s cons Introduction to s cons Presentation Transcript

    • Introduction to SCons Steve Christensen [email_address] Presented to Utah Python Users Group
    • What is SCons?
      • SCons is an Open Source software construction tool
      • Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache.
      • In short, SCons is an easier, more reliable way to build software.
    • SCons Benefits
      • Both SCons configuration files and user-created extensions to SCons are Python scripts
      • Global view of dependencies for entire project.
      • Support for sharing cached build results among developers
    • SCons Benefits (continued)
      • Improved support for parallel builds -- like ‘make –j’ but keeps N jobs running simultaneously regardless of directory hierarchy.
      • Reliable detection of build changes using MD5 signatures (signatures track file content as well as command-line options)
    • SCons Benefits (continued)
      • Reliable, automatic dependency analysis for C, C++, and Fortran. (extendible)
      • Built-in support for C, C++, D, Java, Fortran, Yacc, Lex, Qt, SWIG, building TeX and LaTeX documents, and many others. (extendible)
      • Great way for Python to infiltrate your C/C++ work environment
    • SCons Drawbacks
      • Java support isn’t as complete as the C/C++ support
      • Incremental / no-op build performance is bad.
        • Compared to other tools, SCons can be significantly slower (e.g. 1-2 minute no-op build?)
        • Recipes on the Wiki / Mail Lists for speed ups
      • Complex builds require a fair amount of Python code to achieve the functionality built- in to some other build tools (e.g. variant builds ala BoostJam)
    • SCons Basics
      • At startup, SCons will look for a file named ‘SConstruct’ in the current directory.
      • SConstruct is a Python script. SCons processes the script to build a dependency graph. Any nodes in the dependency graph that are out-of-date will be rebuilt.
      • SCons tracks dependencies by creating ‘.sconsign’ files to store build signatures.
    • Example #1: HelloWorld
      • Simple helloworld.c :
      • int main() {
      • printf(“Hello, world!n”);
      • }
      • Simple SConstruct:
      • Program('helloworld.c')
    • Example #2: Static Libraries
    • Example #2.1 : Shared Libraries
    • Example #3: Builders return Lists
    • Example #3.1 : Why lists?
      • In addition to file prefix / suffix problems, the same builder may produce a different number of output files on different platforms / compilers.
      • E.g. SharedLibrary(‘foo’,foo_sources) will return a single-item list on win32/cygwin [<Node: ‘foo.dll’>], and a three-item list on win32/msvc [<Node: ‘foo.dll’>,<Node: ‘foo.lib’>, <Node: ‘foo.exp’>]
    • Example #4: Construction Environments
      • What if we want to compile the program in multiple ways?
    • Example #4.2: Modifying a Construction Environment
      • Result:
      • gcc -DFIRST -DDEFINE2 -DLAST -c -o helloworld.o helloworld.c
      • gcc -o helloworld.exe helloworld.o
    • Hierarchical Builds
      • Source files of large projects are typically organized into a hierarchy of directories. Builds with SCons use a hierarchy of SCons build scripts.
      • The top-level build script remains named ‘SConstruct’
      • The lower-level build scripts are conventionally named ‘SConscript’, and are executed via SConscript() method in the calling script(s).
    • Example #5: Heirarchical Builds
    • Example #6: Source vs. Build Directories?
    • Variant Builds
      • BuildDir is cool, but I want release / debug and win32 / cygwin binaries and objects built into separate trees.
      • And, I want separate bin/lib/obj directories.
    • Example #7: Variant Builds
    • Example #7: Variant Builds (cont’d)
    • Example #7: Variant Builds (cont’d)
    • Example #8: Caching Built Files
      • Need a network share with read/write access for all your developers
      • Add ‘CacheDir(“/my/fancy/bulidcache”)’ to your build script.
      • Command-line options can be used to enable or disable uploads/downloads from the cache.
    • Example #9: Extending SCons
    • Example #9: Extending SCons
      • sed 's/x/y/' < > baz.out
    • Example #9: Extending SCons
      • sed 's/x/y/' < baz.input > baz.output
    • Example #9: Extending SCons
    • Example #10: Java Builds
    • Example #11: MSVC PDB, PCH, Resources
    • More examples?
      • Options?
      • Configuration?
    • References
      • SCons Homepage
      • SCons Wiki
      • Article ( Make Alternatives
      • Article (Games from Within): The Quest for the Perfect Build System