Building software with SCons requires to have Python and SCons installed.
As SCons is only made of Python modules, the sources may be shipped with your project if your clients can not install dependencies. All the following exemples can be downloaded at the end of that blog.
First a Fortran 77 program will be built made of two files:
$ cd fortran-project $ scons -Q gfortran -o cfib.o -c cfib.f gfortran -o fib.o -c fib.f gfortran -o compute-fib cfib.o fib.o $ ./compute-fib First 10 Fibonacci numbers: 0. 1. 1. 2. 3. 5. 8. 13. 21. 34.
The '-Q' option tell to Scons to be less verbose. For cleaning the project, add the '-c' option:
$ scons -Qc Removed cfib.o Removed fib.o Removed compute-fib
From this first example, it can been seen that SCons find the 'gfortran' tool from the file extension. Then have a look at the user's manual if you want to set a particular tool.
A second C program will directly run the execution from the SCons file by adding a test command:
$ cd c-project $ scons -Q run-test gcc -o test.o -c test.c gcc -o fact.o -c fact.c ar rc libfact.a fact.o ranlib libfact.a gcc -o test-fact test.o libfact.a run_test(["run-test"], ["test-fact"]) OK
However running scons alone builds only the main program:
$ scons -Q gcc -o main.o -c main.c gcc -o compute-fact main.o libfact.a $ ./compute-fact Computing factorial for: 5 Result: 120
This second example shows that the construction dependency is described by passing Python objects. An interesting point is the possibility to add your own Python functions in the build process.
A third C++ program will create a shared library used for two different programs: the main application and a test suite. The main application can be built by:
$ cd cxx-project $ scons -Q g++ -o main.o -c -Imbdyn-src main.cxx g++ -o mbdyn-src/nodes.os -c -fPIC -Imbdyn-src mbdyn-src/nodes.cxx g++ -o mbdyn-src/solver.os -c -fPIC -Imbdyn-src mbdyn-src/solver.cxx g++ -o mbdyn-src/libmbdyn.so -shared mbdyn-src/nodes.os mbdyn-src/solver.os g++ -o mbdyn main.o -Lmbdyn-src -lmbdyn
It shows that SCons handles for us the compilation flags for creating a shared library according to the tool (-fPIC). Moreover extra environment variables have been given (CPPPATH, LIBPATH, LIBS), which are all translated for the chosen tool. All those variables can be found in the user's manual or in the man page. The building and running of the test suite is made by giving an extra variable:
$ TEST_CMD="LD_LIBRARY_PATH=mbdyn-src ./%s" scons -Q run-tests g++ -o tests/run_all_tests.o -c -Imbdyn-src tests/run_all_tests.cxx g++ -o tests/test_solver.o -c -Imbdyn-src tests/test_solver.cxx g++ -o tests/all-tests tests/run_all_tests.o tests/test_solver.o -Lmbdyn-src -lmbdyn run_test(["tests/run-tests"], ["tests/all-tests"]) OK
That is rather convenient to build softwares by manipulating Python objects, moreover custom actions can be added in the process. SCons has also a configuration mechanism working like autotools macros that can be discovered in the user's manual.
- logilab-xmltools High level tools to help using XML in Python
- The Python Package Index is not a "Software Distribution"
- qgpibplotter is (hopefully) working
- pyreverse http://www.logilab.org/project/pylint a set of tools for reverse engineering Python code.
- Reinteract: un outil intéressant pour faire du numpy/scipy