Differences between version 8 and revision by previous author of MakeToSCons.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 8 | Last edited on Monday, October 11, 2004 10:59:33 pm | by SamJansen | Revert |
| Older page: | version 4 | Last edited on Tuesday, June 1, 2004 9:57:40 am | by DanielLawson | Revert |
@@ -11,9 +11,9 @@
!!! Should I use SCons too?
Maybe. SCons requires that whoever has to compile the software has both Python and SCons installed. If this is an acceptable requirement, then the answer is probably "yes".
-The worst thing about SCons is that it does take some time to learn. It is not hard to learn; being based on the simple but powerful programming language Python helps here, but it can be hard to make the leap from a system you already know to a new one, even if the old system is inferior, simply because of the extra time it takes to learn the new system. However, I (SamJansen) recommend learning modern build systems that don't emply
make.
+The worst thing about SCons is that it does take some time to learn. It is not hard to learn; being based on the simple but powerful programming language Python helps here, but it can be hard to make the leap from a system you already know to a new one, even if the old system is inferior, simply because of the extra time it takes to learn the new system. However, I (SamJansen) recommend learning modern build systems that don't employ
make.
!!! The simple stuff
SCons does a few things for free. Dependency tracking is the first one that springs to mind. Consider the following makefile and its SCons equivalent:
@@ -27,9 +27,9 @@
Both of these work the same at the first glance, though I believe the SConstruct (yes, SConstruct is the name of the file that replaces your Makefile) file a lot more readable. However the SCons file has the following extra features:
* Proper dependency tracking. SCons scans the source file for headers so it knows when each file needs to be compiled. Make has no knowledge of this by default, and doing proper dependency tracking in make is quite a nightmare (but possible).
* MD5Sum based checking of the source files to see which ones need to be recompiled. Make uses timestamps, which is also an option for SCons.
-* No explicit rules needed for this simple example. In the makefile the linking line was still necessary (along with the strange syntax: a casual reader has no idea what $@ and $^ mean). ''Note, the linking line isn't needed in a Makefile -- DanielLawson
''
+* No explicit rules needed for this simple example. In the makefile the linking line was still necessary (along with the strange syntax: a casual reader has no idea what $@ and $^ mean). ''Note, the linking line isn't needed in a Makefile, if there is a dependancy with the same base name as the target, eg foo: foo.o bar.o will automatically link for you. Make has a lot of implicit rules, it pays to read about them
-- Daniel Lawson
''
* You can automatically clean the build with __scons -c__. This cleans only the files generated in the build. Clean rules have to be specified by the programmer in makefiles.
* Even works in Windows with the MicrosoftVisualStudio C Compiler.
!! Setting CFLAGS and similar
@@ -54,11 +54,19 @@
It is simplicity itself to include multiple files in the build. Remember that SCons is Python-based?
# SConstruct file
import glob
- Library(glob.glob('*.c') + glob.gloc
('source_dir_2/*.cc'), 'sam')
+ Library(glob.glob('*.c') + glob.glob
('source_dir_2/*.cc'), 'sam')
Python's ''glob'' module does all the hard work. Again, full dependency tracking and all other features of SCons work correctly.
!! Hierarchical builds
SCons supports hierarchical builds with the use of the ''SConscript'' directive. These scripts will be read and their information processed. A new SCons is not forked for every ''SConscript'' directive, unlike the usual recursive make solution.
+
+Including other directories in the build is as simple as:
+
+ # SConstruct file
+ SConscript("dir1/")
+ SConscript("dir2/")
+
+This will read in the ''SConscript'' files in ''dir1'' and ''dir2''. It is possible to export environments to these other scripts if needs be.
