From: bdbaddog Date: Tue, 19 Jan 2010 05:59:03 +0000 (+0000) Subject: Merge back from checkpoint. X-Git-Url: http://git.tremily.us/?p=scons.git;a=commitdiff_plain;h=699ae9b4e931d17d21f6c445f6e93f3bb7c7e2b1 Merge back from checkpoint. Need to regenerate the .xml files. git-svn-id: http://scons.tigris.org/svn/scons/trunk@4635 fdb21ef1-2011-0410-befe-b5e4ea1792b1 --- diff --git a/Announcement.txt b/Announcement.txt index 384f5455..521dd711 100644 --- a/Announcement.txt +++ b/Announcement.txt @@ -1,71 +1,187 @@ __COPYRIGHT__ __FILE__ __REVISION__ __DATE__ __DEVELOPER__ - - A new SCons checkpoint release, 0.XX.0dYYYYMMDD, is now available at the - SCons download page: - - http://www.scons.org/download.php - - A SCons "checkpoint release" is intended to provide early access to - new features so they can be tested in the field before being released - for adoption by other software distributions. - - Note that a checkpoint release is developed using the same test-driven - development methdology as all SCons releases. Existing SCons - functionality should all work as it does in previous releases (except - for any changes identified in the release notes) and early adopters - should be able to use a checkpoint release safely for production work - with existing SConscript files. If not, it represents not only a bug - in SCons but also a hole in the regression test suite, and we want to - hear about it. - - New features may be more lightly tested than in past releases, - especially as concerns their interaction with all of the other - functionality in SCons. We are especially interested in hearing bug - reports about new functionality. - - We do not recommend that downstream distributions (Debian, Fedora, - etc.) package a checkpoint release, mainly to avoid confusing the - "public" release numbering with the long checkpoint release names. - - Here is a summary of the changes since 0.XX: - - NEW FUNCTIONALITY - - - List new features (presumably why a checkpoint is being released) - - DEPRECATED FUNCTIONALITY - - - List anything that's been deprecated since the last release - - CHANGED/ENHANCED EXISTING FUNCTIONALITY - - - List modifications to existing features, where the previous behavior - wouldn't actually be considered a bug - - FIXES - - - List fixes of outright bugs - - IMPROVEMENTS - - - List improvements that wouldn't be visible to the user in the - documentation: performance improvements (describe the circumstances - under which they would be observed), or major code cleanups - - PACKAGING - - - List changes in the way SCons is packaged and/or released - - DOCUMENTATION - - - List any significant changes to the documentation (not individual - typo fixes, even if they're mentioned in src/CHANGES.txt to give - the contributor credit) - - DEVELOPMENT - - - List visible changes in the way SCons is developed - - Thanks to LARRY, MOE and CURLY for their contributions to this release. - +SCons checkpoint release 1.2.0.d20090223 is now available at the SCons +download page: + + http://www.scons.org/download.php + +This checkpoint provides early access to new features and fixes +scheduled for release in SCons 1.3.0. + + +IMPORTANT: + +- This checkpoint release notably contains completely new code for + detecting installed versions of Microsoft Visual C/C++. The new code + has been tested extensively, but it is possible that it will fail to + find installed versions on configurations that we don't have available + for testing. Please report *any* problems with support for Microsoft + Visual C/C++ as soon as possible so that we can diagnose and fix + them before releasing SCons 1.3.0. + +- Python versions prior to 2.4 are supported by SCons 1.2.0, but are + officially deprecated and will generate a disableable warning message. + We plan to remove support for these older versions in SCons 2.0. + If removing this support would cause a problem for you, please contact + the dev@scons.tigris.org mailing list. + +- The following deprecated features will still be supported in 1.3.0 + but will generate mandatory, non-disableable warnings: + + -- Support for Python versions 1.5, 1.6, 2.0, 2.1, 2.2, and 2.3. + -- The overrides= keyword argument to the Builder() call. + -- The scanner= keyword argument to the Builder() call. + -- The BuildDir() function and env.BuildDir() method. + -- The env.Copy() method. + -- The SourceSignatures() function and + env.SourceSignatures() method. + -- The TargetSignatures() function and + env.TargetSignatures() method. + -- The Sig module (now an unnused stub). + -- The --debug=dtree, --debug=stree and --debug=tree options. + -- The --debug=nomemoizer option. + -- The Options object and the related BoolOption(), EnumOption(), + ListOption(), PackageOption() and PathOption() functions. + + +WHAT'S NEW IN THIS RELEASE + +For a complete description of important changes since other recent +releases, see: + + http://www.scons.org/RELEASE.txt + +For a complete list of changes in all releases, see the official +change log: + + http://www.scons.org/CHANGES.txt + +We do not recommend that downstream distributions (Debian, Fedora, +etc.) package a checkpoint release, mainly to avoid confusing the +"public" release numbering with the long checkpoint release names. + + +Here is a summary of all changes since the 1.1.0 release: + + +NEW FUNCTIONALITY + +- SCons now supports batch compilation of Visual Studio C/C++ source + files when the new $MSVC_BATCH construction variable is set. +- New reserved $CHANGED_SOURCES, $CHANGED_TARGETS, $UNCHANGED_SOURCES + and $UNCHANGED_TARGETS variables provide finer-grained control + over what source or targets to pass to a command line. +- A new batch_key= keyword argument to Action object creation supports + general batched builds. +- A new --warn=future-deprecated option provides advance warnings about + future deprecated features that still have warnings hidden by default. +- Visual Studio 8 project files can now be generated for 64-bit platforms. +- Visual Studio & Visual C++ now support TARGET_OS, TARGET_ARCH for + cross-compiling to x86, x86_64, ia64 + +CHANGED/ENHANCED EXISTING FUNCTIONALITY + +- $CCFLAGS is no longer included in the default definitions of $CXXFLAGS + for Visual C/C++ and MIPSpro C++ on SGI (to match other tools and + avoid flag duplication on C++ command lines). +- The $CCFLAGS variable is now passed to Visual C/C++ precompiled header + compilation. +- Scanning files encoded in utf-8 and utf-16 for implicit dependencies + is now supported. +- Linker tools modules now differentiate properly between the SharedLibrary + and LoadableModule Builders. +- Don't automatically try to build .pdf graphics files for .eps files in + \includegraphics{} calls in TeX/LaTeX files when building with the PDF + builder (and thus using pdflatex). +- Setting WINDOWS_INSERT_DEF=0 now disables --output-def when linking + under MinGW. +- AppendENVPath() and PrependENVPath() now interpret '#' in paths + relative to the top-level SConstruct directory. +- The message, "scons: Build interrupted." is no printed on error output, + not standard output. +- Quoted module names in SWIG source files are no handled correctly. +- Suffix-matching for scanners is now case-insensitive on Windows. +- Generated Visual Studio 8 project files now work better with + IntelliSense, by defining IncludeSearchPath and PreprocessorDefinitions. +- Unnecessary nested $( $) strings around $_LIBDIRFLAGS have been removed + from the default command lines for the Microsoft linker, the OS/2 + ilink linker and the Phar Lap linkloc linker. +- SCons now internally spells the Windows environment variables + "SystemDrive" and "SystemRoot" (instead of "SYSTEMDRIVE" and + "SYSTEMROOT.") +- Major revamp of Visual Studio/Visual C++ logic for locating and + configuring available version on the machine. + +FIXES + +- The $CHANGED_SOURCES variable now correctly includes files whose + corresponding targets don't exist. +- The $CHANGED_SOURCES variable now works correctly with the + --config=force option. +- $SOURCE and $SOURCES attributes now work even when there are no + sources specified in the Builder call. +- $SWIGOUTDIR values with spaces now work properly. +- Fix use of $SWIGOUTDIR when generating Python wrappers. +- Add $SWIGDIRECTORSUFFIX and $SWIGVERSION construction variables. +- The Borland ilink linker now uses the -e option to specify the output + file name. +- SCons now correctly identifies shared libraries and shared object files + in a Repository. +- Implicit command dependencies are detected even when the first argument + is quoted on the command line. +- #include file names that contain escaped backslashes (\\) are now + handled correctly. +- Have AddOption() remove variables from the list of + seen-but-unknown variables (which are reported later). +- An option name and aliases can now be specified as a tuple. +- Textfile builder. +- Fix the -n option when used with VariantDir(duplicate=1) + and the variant directory doesn't already exist. +- Fix scanning of Unicode files for both UTF-16 endian flavors. +- Fix a TypeError on #include of file names with Unicode characters. +- Fix an exception if a null command-line argument is passed in. +- Evaluate Requires() prerequisites before a Node's direct children + (sources and dependencies). +- Remove redundant __metaclass__ initializations in Environment.py. +- Fix SWIG testing infrastructure to work on Mac OS X. +- Substfile builder. +- When reporting a target that SCons doesn't know how to make, + specify whether it's a File, Dir, etc. +- Add -recorder flag to Latex commands and updated internals to + use the output to find files TeX creates. This allows the MiKTeX + installations to find the created files +- Notify user of Latex errors that would get buried in the + Latex output +- Remove LATEXSUFFIXES from environments that don't initialize Tex. +- Add support for the glosaaries package for glossaries and acronyms +- Fix problem that pdftex, latex, and pdflatex tools by themselves did + not create the actions for bibtex, makeindex,... by creating them + and other environment settings in one routine called by all four + tex tools. +- Fix problem with filenames of sideeffects when the user changes + the name of the output file from the latex default + + + + +DOCUMENTATION + +- The TestCommon.shobj_prefix variable is now documented. +- Document that the msvc Tool module uses $PCH, $PCHSTOP and $PDB. +- The User's Guide has had numerous typos fixed and other corrections. +- Document that filenames with '.' as the first character are + ignored by Glob() by default (matching UNIX glob semantics). +- Correct the documentation of text returned by sconf.Result(). + + +Thanks to Stanislav Baranov, David Cornapeau, Robert P.J. Day, +Lukas Erlinghagen, Allan Erskine, Hartmut Goebel, Jared Grubb, +Mateusz Gruca, Jim Hunziker, Ted Johnson, Jason Kenney, Steven Knight, +Arve Knudsen, Rob Managan, Greg Noel, Gary Oberbrunner, Zia Sobhani, +Greg Spencer, Roberto de Vecchi, Ben Webb and Matthew Wesley, +Steven Knight for their contributions to this release. + + +On behalf of the SCons team, + + --WPD diff --git a/QMTest/TestSCons.py b/QMTest/TestSCons.py index ce011741..d8dda8a9 100644 --- a/QMTest/TestSCons.py +++ b/QMTest/TestSCons.py @@ -52,7 +52,7 @@ from TestCommon import __all__ default_version = '1.2.0' -copyright_years = '2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009' +copyright_years = '2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010' # In the checked-in source, the value of SConsVersion in the following # line must remain "__ VERSION __" (without the spaces) so the built diff --git a/SConstruct b/SConstruct index b52acaf6..1c2cc47e 100644 --- a/SConstruct +++ b/SConstruct @@ -6,10 +6,10 @@ # When this gets changed, you must also change the copyright_years string # in QMTest/TestSCons.py so the test scripts look for the right string. -copyright_years = '2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009' +copyright_years = '2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010' # This gets inserted into the man pages to reflect the month of release. -month_year = 'February 2009' +month_year = 'January 2010' # # __COPYRIGHT__ diff --git a/doc/user/add-method.xml b/doc/user/add-method.xml index d4a484e9..8e078fd5 100644 --- a/doc/user/add-method.xml +++ b/doc/user/add-method.xml @@ -56,7 +56,7 @@ % scons -Q / - cc -o hello.o -c hello.c + [?1034hcc -o hello.o -c hello.c cc -o hello hello.o Install file: "hello" as "/usr/bin/hello" Install file: "hello" as "install/bin/hello" @@ -100,7 +100,7 @@ % scons -Q - cc -o test_stuff.o -c test_stuff.c + [?1034hcc -o test_stuff.o -c test_stuff.c cc -o tests/test_stuff test_stuff.o @@ -110,9 +110,40 @@ C:\>scons -Q - rc /fores.res res.rc - cl /Fotest_stuff.obj /c test_stuff.c /nologo - link /nologo /OUT:tests\test_stuff.exe test_stuff.obj res.res + IndexError: list index out of range: + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\Main.py", line 1294: + _exec_main(parser, values) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\Main.py", line 1259: + _main(parser) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\Main.py", line 929: + SCons.Script._SConscript._SConscript(fs, script) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\SConscript.py", line 179: + exec sys.stdin in call_stack[-1].globals + File "<stdin>", line 219: + None + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\SConscript.py", line 614: + env = self.factory() + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\SConscript.py", line 594: + default_env = SCons.Defaults.DefaultEnvironment() + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Defaults.py", line 91: + _default_env = apply(SCons.Environment.Environment, args, kw) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Environment.py", line 1004: + apply_tools(self, tools, toolpath) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Environment.py", line 106: + env.Tool(tool) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Environment.py", line 1703: + tool(self) + File "<stdin>", line 67: + None + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Tool\msvc.py", line 239: + mssdk.generate(env) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Tool\mssdk.py", line 41: + mssdk_setup_env(env) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Tool\MSCommon\sdk.py", line 298: + mssdk = get_default_sdk() + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Tool\MSCommon\sdk.py", line 262: + return InstalledSDKList[0] + [?1034h diff --git a/doc/user/alias.xml b/doc/user/alias.xml index f285d70d..9c4a179d 100644 --- a/doc/user/alias.xml +++ b/doc/user/alias.xml @@ -46,7 +46,7 @@ % scons -Q install - cc -o hello.o -c hello.c + [?1034hcc -o hello.o -c hello.c cc -o hello hello.o Install file: "hello" as "/usr/bin/hello" @@ -86,23 +86,23 @@ % scons -Q install-bin - cc -o foo.o -c foo.c + [?1034hcc -o foo.o -c foo.c cc -o foo foo.o Install file: "foo" as "/usr/bin/foo" % scons -Q install-lib - cc -o bar.o -c bar.c + [?1034hcc -o bar.o -c bar.c ar rc libbar.a bar.o ranlib libbar.a Install file: "libbar.a" as "/usr/lib/libbar.a" % scons -Q -c / - Removed foo.o + [?1034hRemoved foo.o Removed foo Removed /usr/bin/foo Removed bar.o Removed libbar.a Removed /usr/lib/libbar.a % scons -Q install - cc -o foo.o -c foo.c + [?1034hcc -o foo.o -c foo.c cc -o foo foo.o Install file: "foo" as "/usr/bin/foo" cc -o bar.o -c bar.c diff --git a/doc/user/builders-built-in.xml b/doc/user/builders-built-in.xml index 738683bc..cb7fb70e 100644 --- a/doc/user/builders-built-in.xml +++ b/doc/user/builders-built-in.xml @@ -144,7 +144,7 @@ % scons -Q - cc -o goodbye.o -c goodbye.c + [?1034hcc -o goodbye.o -c goodbye.c cc -o hello.o -c hello.c cc -o hello hello.o goodbye.o -L/usr/dir1 -Ldir2 -lfoo1 -lfoo2 @@ -157,9 +157,40 @@ C:\>scons -Q - cl /Fogoodbye.obj /c goodbye.c /nologo - cl /Fohello.obj /c hello.c /nologo - link /nologo /OUT:hello.exe /LIBPATH:\usr\dir1 /LIBPATH:dir2 foo1.lib foo2.lib hello.obj goodbye.obj + IndexError: list index out of range: + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\Main.py", line 1294: + _exec_main(parser, values) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\Main.py", line 1259: + _main(parser) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\Main.py", line 929: + SCons.Script._SConscript._SConscript(fs, script) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\SConscript.py", line 179: + exec sys.stdin in call_stack[-1].globals + File "<stdin>", line 219: + None + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\SConscript.py", line 614: + env = self.factory() + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Script\SConscript.py", line 594: + default_env = SCons.Defaults.DefaultEnvironment() + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Defaults.py", line 91: + _default_env = apply(SCons.Environment.Environment, args, kw) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Environment.py", line 1004: + apply_tools(self, tools, toolpath) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Environment.py", line 106: + env.Tool(tool) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Environment.py", line 1703: + tool(self) + File "<stdin>", line 67: + None + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Tool\msvc.py", line 239: + mssdk.generate(env) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Tool\mssdk.py", line 41: + mssdk_setup_env(env) + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Tool\MSCommon\sdk.py", line 298: + mssdk = get_default_sdk() + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Tool\MSCommon\sdk.py", line 262: + return InstalledSDKList[0] + [?1034h @@ -727,7 +758,7 @@ % scons -Q . - tar -c -f out1.tar file1 file2 + [?1034htar -c -f out1.tar file1 file2 tar -c -f out2.tar directory @@ -753,185 +784,3 @@ % scons -Q . - tar -c -z -f out.tar.gz directory - - - - - you may also wish to set the value of the - &cv-link-TARSUFFIX; construction variable - to your desired suffix for compress &tar; archives, - so that &SCons; can append it to the target file name - without your having to specify it explicitly: - - - - - env = Environment(TARFLAGS = '-c -z', - TARSUFFIX = '.tgz') - env.Tar('out', 'directory') - - - - % scons -Q . - tar -c -z -f out.tgz directory - - - - -
- The &Zip; Builder - - - - The &b-link-Zip; Builder object creates archives of files - and/or directory trees in the ZIP file format. - Python versions 1.6 or later - contain an internal &zipfile; module - that &SCons; will use. - In this case, given the following - &SConstruct; file: - - - - - env = Environment() - env.Zip('out', ['file1', 'file2']) - - - - - Your output will reflect the fact - that an internal Python function - is being used to create the output ZIP archive: - - - - - % scons -Q . - zip(["out.zip"], ["file1", "file2"]) - - - - - If you're using Python version 1.5.2 to run &SCons;, - then &SCons; will try to use an external - &zip; program as follows: - - - - - % scons -Q . - zip /home/my/project/zip.out file1 file2 - - -
- - - -
- Java - - - - &SCons; provides Builder objects - for creating various types of Java output files. - - - -
- Building Class Files: the &Java; Builder - - - - The &b-link-Java; builder takes one or more input - .java files - and turns them into one or more - .class files - Unlike most builders, however, - the &Java; builder takes - target and source directories, - not files, as input. - - - - - env = Environment() - env.Java(target = 'classes', source = 'src') - - - - - The &Java; builder will then - search the specified source directory - tree for all .java files, - and pass any out-of-date - - - - - XXX Java() screen - - -
- -
- The &Jar; Builder - - - - XXX The &Jar; builder object - - - - - env = Environment() - env.Java(target = 'classes', source = 'src') - env.Jar(target = '', source = 'classes') - - - - XXX Jar() screen - - -
- -
- Building C header and stub files: the &JavaH; Builder - - - - XXX JavaH() para - - - - - XXX JavaH() programlisting - - - - XXX JavaH() screen - - -
- -
- Building RMI stub and skeleton class files: the &RMIC; Builder - - - - XXX RMIC() para - - - - - XXX RMIC() programlisting - - - - XXX RMIC() screen - - -
- -
diff --git a/doc/user/builders-commands.xml b/doc/user/builders-commands.xml index fcb2a96d..23fe4ce4 100644 --- a/doc/user/builders-commands.xml +++ b/doc/user/builders-commands.xml @@ -85,62 +85,3 @@ % scons -Q - sed 's/x/y/' < foo.in > foo.out - - - - - This is often more convenient than - creating a &Builder; object - and adding it to the &cv-link-BUILDERS; variable - of a &consenv; - - - - - - Note that the action you specify to the - &Command; &Builder; can be any legal &SCons; &Action;, - such as a Python function: - - - - - env = Environment() - def build(target, source, env): - # Whatever it takes to build - return None - env.Command('foo.out', 'foo.in', build) - - - - - Which executes as follows: - - - - - % scons -Q - build(["foo.out"], ["foo.in"]) - - - - - Note that &cv-link-SOURCE; and &cv-link-TARGET; are expanded - in the source and target as well as of SCons 1.1, - so you can write: - - - - - env.Command('${SOURCE.basename}.out', 'foo.in', build) - - - - - - which does the same thing as the previous example, but allows you - to avoid repeating yourself. - - - diff --git a/doc/user/builders-writing.xml b/doc/user/builders-writing.xml index 3932181b..e69de29b 100644 --- a/doc/user/builders-writing.xml +++ b/doc/user/builders-writing.xml @@ -1,957 +0,0 @@ - - - - - - - Although &SCons; provides many useful methods - for building common software products: - programs, libraries, documents. - you frequently want to be - able to build some other type of file - not supported directly by &SCons;. - Fortunately, &SCons; makes it very easy - to define your own &Builder; objects - for any custom file types you want to build. - (In fact, the &SCons; interfaces for creating - &Builder; objects are flexible enough and easy enough to use - that all of the the &SCons; built-in &Builder; objects - are created the mechanisms described in this section.) - - - -
- Writing Builders That Execute External Commands - - - - The simplest &Builder; to create is - one that executes an external command. - For example, if we want to build - an output file by running the contents - of the input file through a command named - foobuild, - creating that &Builder; might look like: - - - - - bld = Builder(action = 'foobuild < $SOURCE > $TARGET') - - - - - All the above line does is create a free-standing - &Builder; object. - The next section will show us how to actually use it. - - - -
- -
- Attaching a Builder to a &ConsEnv; - - - - A &Builder; object isn't useful - until it's attached to a &consenv; - so that we can call it to arrange - for files to be built. - This is done through the &cv-link-BUILDERS; - &consvar; in an environment. - The &cv-BUILDERS; variable is a Python dictionary - that maps the names by which you want to call - various &Builder; objects to the objects themselves. - For example, if we want to call the - &Builder; we just defined by the name - Foo, - our &SConstruct; file might look like: - - - - - - - bld = Builder(action = 'foobuild < $SOURCE > $TARGET') - env = Environment(BUILDERS = {'Foo' : bld}) - - - - - With the &Builder; attached to our &consenv; - with the name Foo, - we can now actually call it like so: - - - - - env.Foo('file.foo', 'file.input') - - - - - Then when we run &SCons; it looks like: - - - - - % scons -Q - foobuild < file.input > file.foo - - - - - Note, however, that the default &cv-BUILDERS; - variable in a &consenv; - comes with a default set of &Builder; objects - already defined: - &b-link-Program;, &b-link-Library;, etc. - And when we explicitly set the &cv-BUILDERS; variable - when we create the &consenv;, - the default &Builder;s are no longer part of - the environment: - - - - - - bld = Builder(action = 'foobuild < $SOURCE > $TARGET') - env = Environment(BUILDERS = {'Foo' : bld}) - env.Foo('file.foo', 'file.input') - env.Program('hello.c') - - - - % scons -Q - AttributeError: SConsEnvironment instance has no attribute 'Program': - File "/home/my/project/SConstruct", line 4: - env.Program('hello.c') - - - - - To be able to use both our own defined &Builder; objects - and the default &Builder; objects in the same &consenv;, - you can either add to the &cv-BUILDERS; variable - using the &Append; function: - - - - - - - env = Environment() - bld = Builder(action = 'foobuild < $SOURCE > $TARGET') - env.Append(BUILDERS = {'Foo' : bld}) - env.Foo('file.foo', 'file.input') - env.Program('hello.c') - - - - - Or you can explicitly set the appropriately-named - key in the &cv-BUILDERS; dictionary: - - - - - env = Environment() - bld = Builder(action = 'foobuild < $SOURCE > $TARGET') - env['BUILDERS']['Foo'] = bld - env.Foo('file.foo', 'file.input') - env.Program('hello.c') - - - - - Either way, the same &consenv; - can then use both the newly-defined - Foo &Builder; - and the default &b-link-Program; &Builder;: - - - - - % scons -Q - foobuild < file.input > file.foo - cc -o hello.o -c hello.c - cc -o hello hello.o - - -
- -
- Letting &SCons; Handle The File Suffixes - - - - By supplying additional information - when you create a &Builder;, - you can let &SCons; add appropriate file - suffixes to the target and/or the source file. - For example, rather than having to specify - explicitly that you want the Foo - &Builder; to build the file.foo - target file from the file.input source file, - you can give the .foo - and .input suffixes to the &Builder;, - making for more compact and readable calls to - the Foo &Builder;: - - - - - - - bld = Builder(action = 'foobuild < $SOURCE > $TARGET', - suffix = '.foo', - src_suffix = '.input') - env = Environment(BUILDERS = {'Foo' : bld}) - env.Foo('file1') - env.Foo('file2') - - - - % scons -Q - foobuild < file1.input > file1.foo - foobuild < file2.input > file2.foo - - - - - You can also supply a prefix keyword argument - if it's appropriate to have &SCons; append a prefix - to the beginning of target file names. - - - -
- -
- Builders That Execute Python Functions - - - - In &SCons;, you don't have to call an external command - to build a file. - You can, instead, define a Python function - that a &Builder; object can invoke - to build your target file (or files). - Such a &buildfunc; definition looks like: - - - - - def build_function(target, source, env): - # Code to build "target" from "source" - return None - - - - - The arguments of a &buildfunc; are: - - - - - - - target - - - - - A list of Node objects representing - the target or targets to be - built by this builder function. - The file names of these target(s) - may be extracted using the Python &str; function. - - - - - - - source - - - - - A list of Node objects representing - the sources to be - used by this builder function to build the targets. - The file names of these source(s) - may be extracted using the Python &str; function. - - - - - - - env - - - - - The &consenv; used for building the target(s). - The builder function may use any of the - environment's construction variables - in any way to affect how it builds the targets. - - - - - - - - - - The builder function must - return a 0 or None value - if the target(s) are built successfully. - The builder function - may raise an exception - or return any non-zero value - to indicate that the build is unsuccessful, - - - - - - Once you've defined the Python function - that will build your target file, - defining a &Builder; object for it is as - simple as specifying the name of the function, - instead of an external command, - as the &Builder;'s - action - argument: - - - - - def build_function(target, source, env): - # Code to build "target" from "source" - return None - bld = Builder(action = build_function, - suffix = '.foo', - src_suffix = '.input') - env = Environment(BUILDERS = {'Foo' : bld}) - env.Foo('file') - - - - - And notice that the output changes slightly, - reflecting the fact that a Python function, - not an external command, - is now called to build the target file: - - - - - % scons -Q - build_function(["file.foo"], ["file.input"]) - - -
- -
- Builders That Create Actions Using a &Generator; - - - - &SCons; Builder objects can create an action "on the fly" - by using a function called a &generator;. - This provides a great deal of flexibility to - construct just the right list of commands - to build your target. - A &generator; looks like: - - - - - def generate_actions(source, target, env, for_signature): - return 'foobuild < %s > %s' % (target[0], source[0]) - - - - - The arguments of a &generator; are: - - - - - - - source - - - - - A list of Node objects representing - the sources to be built - by the command or other action - generated by this function. - The file names of these source(s) - may be extracted using the Python &str; function. - - - - - - - - target - - - - - A list of Node objects representing - the target or targets to be built - by the command or other action - generated by this function. - The file names of these target(s) - may be extracted using the Python &str; function. - - - - - - - - env - - - - - The &consenv; used for building the target(s). - The generator may use any of the - environment's construction variables - in any way to determine what command - or other action to return. - - - - - - - - for_signature - - - - - A flag that specifies whether the - generator is being called to contribute to a build signature, - as opposed to actually executing the command. - - - - - - - - - - - - - The &generator; must return a - command string or other action that will be used to - build the specified target(s) from the specified source(s). - - - - - - Once you've defined a &generator;, - you create a &Builder; to use it - by specifying the generator keyword argument - instead of action. - - - - - - - def generate_actions(source, target, env, for_signature): - return 'foobuild < %s > %s' % (source[0], target[0]) - bld = Builder(generator = generate_actions, - suffix = '.foo', - src_suffix = '.input') - env = Environment(BUILDERS = {'Foo' : bld}) - env.Foo('file') - - - - % scons -Q - foobuild < file.input > file.foo - - - - - Note that it's illegal to specify both an - action - and a - generator - for a &Builder;. - - - -
- -
- Builders That Modify the Target or Source Lists Using an &Emitter; - - - - &SCons; supports the ability for a Builder to modify the - lists of target(s) from the specified source(s). - You do this by defining an &emitter; function - that takes as its arguments - the list of the targets passed to the builder, - the list of the sources passed to the builder, - and the construction environment. - The emitter function should return the modified - lists of targets that should be built - and sources from which the targets will be built. - - - - - - For example, suppose you want to define a Builder - that always calls a foobuild program, - and you want to automatically add - a new target file named - new_target - and a new source file named - new_source - whenever it's called. - The &SConstruct; file might look like this: - - - - - - - def modify_targets(target, source, env): - target.append('new_target') - source.append('new_source') - return target, source - bld = Builder(action = 'foobuild $TARGETS - $SOURCES', - suffix = '.foo', - src_suffix = '.input', - emitter = modify_targets) - env = Environment(BUILDERS = {'Foo' : bld}) - env.Foo('file') - - - - - And would yield the following output: - - - - - % scons -Q - foobuild file.foo new_target - file.input new_source - - - - - One very flexible thing that you can do is - use a construction variable to specify - different emitter functions for different - construction variable. - To do this, specify a string - containing a construction variable - expansion as the emitter when you call - the &Builder; function, - and set that construction variable to - the desired emitter function - in different construction environments: - - - - - bld = Builder(action = 'my_command $SOURCES > $TARGET', - suffix = '.foo', - src_suffix = '.input', - emitter = '$MY_EMITTER') - def modify1(target, source, env): - return target, source + ['modify1.in'] - def modify2(target, source, env): - return target, source + ['modify2.in'] - env1 = Environment(BUILDERS = {'Foo' : bld}, - MY_EMITTER = modify1) - env2 = Environment(BUILDERS = {'Foo' : bld}, - MY_EMITTER = modify2) - env1.Foo('file1') - env2.Foo('file2') - import os - env1['ENV']['PATH'] = env2['ENV']['PATH'] + os.pathsep + os.getcwd() - env2['ENV']['PATH'] = env2['ENV']['PATH'] + os.pathsep + os.getcwd() - - - - - - bld = Builder(action = 'my_command $SOURCES > $TARGET', - suffix = '.foo', - src_suffix = '.input', - emitter = '$MY_EMITTER') - def modify1(target, source, env): - return target, source + ['modify1.in'] - def modify2(target, source, env): - return target, source + ['modify2.in'] - env1 = Environment(BUILDERS = {'Foo' : bld}, - MY_EMITTER = modify1) - env2 = Environment(BUILDERS = {'Foo' : bld}, - MY_EMITTER = modify2) - env1.Foo('file1') - env2.Foo('file2') - - - - - - In this example, the modify1.in - and modify2.in files - get added to the source lists - of the different commands: - - - - - % scons -Q - my_command file1.input modify1.in > file1.foo - my_command file2.input modify2.in > file2.foo - - -
- - - -
- Where To Put Your Custom Builders and Tools - - - - The site_scons directory gives you a place to - put Python modules you can import into your &SConscript; files - (site_scons), - add-on tools that can integrate into &SCons; - (site_scons/site_tools), - and a site_scons/site_init.py file that - gets read before any &SConstruct; or &SConscript; file, - allowing you to change &SCons;'s default behavior. - - - - - - If you get a tool from somewhere (the &SCons; wiki or a third party, - for instance) and you'd like to use it in your project, the - site_scons dir is the simplest place to put it. - Tools come in two flavors; either a Python function that operates on - an &Environment; or a Python file containing two functions, - exists() and generate(). - - - - - - A single-function Tool can just be included in your - site_scons/site_init.py file where it will be - parsed and made available for use. For instance, you could have a - site_scons/site_init.py file like this: - - - - - def TOOL_ADD_HEADER(env): - """A Tool to add a header from $HEADER to the source file""" - add_header = Builder(action=['echo "$HEADER" > $TARGET', - 'cat $SOURCE >> $TARGET']) - env.Append(BUILDERS = {'AddHeader' : add_header}) - env['HEADER'] = '' # set default value - - - - - and a &SConstruct; like this: - - - - - # Use TOOL_ADD_HEADER from site_scons/site_init.py - env=Environment(tools=['default', TOOL_ADD_HEADER], HEADER="=====") - env.AddHeader('tgt', 'src') - - - - - The TOOL_ADD_HEADER tool method will be - called to add the AddHeader tool to the - environment. - - - - - - - Similarly, a more full-fledged tool with - exists() and generate() - methods can be installed in - site_scons/site_tools/toolname.py. Since - site_scons/site_tools is automatically added - to the head of the tool search path, any tool found there will be - available to all environments. Furthermore, a tool found there - will override a built-in tool of the same name, so if you need to - change the behavior of a built-in tool, site_scons gives you the - hook you need. - - - - Many people have a library of utility Python functions they'd like - to include in &SConscript;s; just put that module in - site_scons/my_utils.py or any valid Python module name of your - choice. For instance you can do something like this in - site_scons/my_utils.py to add - build_id and MakeWorkDir - functions: - - - - from SCons.Script import * # for Execute and Mkdir - def build_id(): - """Return a build ID (stub version)""" - return "100" - def MakeWorkDir(workdir): - """Create the specified dir immediately""" - Execute(Mkdir(workdir)) - - - - - And then in your &SConscript; or any sub-&SConscript; anywhere in - your build, you can import my_utils and use it: - - - - - import my_utils - print "build_id=" + my_utils.build_id() - my_utils.MakeWorkDir('/tmp/work') - - - - Note that although you can put this library in - site_scons/site_init.py, - it is no better there than site_scons/my_utils.py - since you still have to import that module into your &SConscript;. - Also note that in order to refer to objects in the SCons namespace - such as &Environment; or &Mkdir; or &Execute; in any file other - than a &SConstruct; or &SConscript; you always need to do - - - from SCons.Script import * - - - - This is true in modules in site_scons such as - site_scons/site_init.py as well. - - - - - If you have a machine-wide site dir you'd like to use instead of - ./site_scons, use the - --site-dir option to point to your dir. - site_init.py and - site_tools will be located under that dir. - To avoid using a site_scons dir at all, even - if it exists, use the --no-site-dir option. - - - -
- - - diff --git a/doc/user/builders.xml b/doc/user/builders.xml index f3989ef3..e69de29b 100644 --- a/doc/user/builders.xml +++ b/doc/user/builders.xml @@ -1,57 +0,0 @@ - - - - - - -This appendix contains descriptions of all of the -Builders that are potentially -available "out of the box" in this version of SCons. - - - - - -&builders-gen; - - diff --git a/doc/user/caching.xml b/doc/user/caching.xml index 2348d329..e69de29b 100644 --- a/doc/user/caching.xml +++ b/doc/user/caching.xml @@ -1,506 +0,0 @@ - - - - - On multi-developer software projects, - you can sometimes speed up every developer's builds a lot by - allowing them to share the derived files that they build. - &SCons; makes this easy, as well as reliable. - - - -
- Specifying the Shared Cache Directory - - - - To enable sharing of derived files, - use the &CacheDir; function - in any &SConscript; file: - - - - - CacheDir('/usr/local/build_cache') - - - - - Note that the directory you specify must already exist - and be readable and writable by all developers - who will be sharing derived files. - It should also be in some central location - that all builds will be able to access. - In environments where developers are using separate systems - (like individual workstations) for builds, - this directory would typically be - on a shared or NFS-mounted file system. - - - - - - Here's what happens: - When a build has a &CacheDir; specified, - every time a file is built, - it is stored in the shared cache directory - along with its MD5 build signature. - - - Actually, the MD5 signature is used as the name of the file - in the shared cache directory in which the contents are stored. - - - On subsequent builds, - before an action is invoked to build a file, - &SCons; will check the shared cache directory - to see if a file with the exact same build - signature already exists. - If so, the derived file will not be built locally, - but will be copied into the local build directory - from the shared cache directory, - like so: - - - - - % scons -Q - cc -o hello.o -c hello.c - cc -o hello hello.o - % scons -Q -c - Removed hello.o - Removed hello - % scons -Q - Retrieved `hello.o' from cache - Retrieved `hello' from cache - - - - - Note that the &CacheDir; feature still calculates - MD5 build sigantures for the shared cache file names - even if you configure &SCons; to use timestamps - to decide if files are up to date. - (See the - chapter for information about the &Decider; function.) - Consequently, using &CacheDir; may reduce or eliminate any - potential performance improvements - from using timestamps for up-to-date decisions. - - - -
- -
- Keeping Build Output Consistent - - - - One potential drawback to using a shared cache - is that the output printed by &SCons; - can be inconsistent from invocation to invocation, - because any given file may be rebuilt one time - and retrieved from the shared cache the next time. - This can make analyzing build output more difficult, - especially for automated scripts that - expect consistent output each time. - - - - - - If, however, you use the --cache-show option, - &SCons; will print the command line that it - would have executed - to build the file, - even when it is retrieving the file from the shared cache. - This makes the build output consistent - every time the build is run: - - - - - % scons -Q - cc -o hello.o -c hello.c - cc -o hello hello.o - % scons -Q -c - Removed hello.o - Removed hello - % scons -Q --cache-show - cc -o hello.o -c hello.c - cc -o hello hello.o - - - - - The trade-off, of course, is that you no longer - know whether or not &SCons; - has retrieved a derived file from cache - or has rebuilt it locally. - - - -
- -
- Not Using the Shared Cache for Specific Files - - - - You may want to disable caching for certain - specific files in your configuration. - For example, if you only want to put - executable files in a central cache, - but not the intermediate object files, - you can use the &NoCache; - function to specify that the - object files should not be cached: - - - - - env = Environment() - obj = env.Object('hello.c') - env.Program('hello.c') - CacheDir('cache') - NoCache('hello.o') - - - - - Then when you run &scons; after cleaning - the built targets, - it will recompile the object file locally - (since it doesn't exist in the shared cache directory), - but still realize that the shared cache directory - contains an up-to-date executable program - that can be retrieved instead of re-linking: - - - - - - - % scons -Q - cc -o hello.o -c hello.c - cc -o hello hello.o - % scons -Q -c - Removed hello.o - Removed hello - % scons -Q - cc -o hello.o -c hello.c - Retrieved `hello' from cache - - -
- -
- Disabling the Shared Cache - - - - Retrieving an already-built file - from the shared cache - is usually a significant time-savings - over rebuilding the file, - but how much of a savings - (or even whether it saves time at all) - can depend a great deal on your - system or network configuration. - For example, retrieving cached files - from a busy server over a busy network - might end up being slower than - rebuilding the files locally. - - - - - - In these cases, you can specify - the --cache-disable - command-line option to tell &SCons; - to not retrieve already-built files from the - shared cache directory: - - - - - % scons -Q - cc -o hello.o -c hello.c - cc -o hello hello.o - % scons -Q -c - Removed hello.o - Removed hello - % scons -Q - Retrieved `hello.o' from cache - Retrieved `hello' from cache - % scons -Q -c - Removed hello.o - Removed hello - % scons -Q --cache-disable - cc -o hello.o -c hello.c - cc -o hello hello.o - - -
- -
- Populating a Shared Cache With Already-Built Files - - - - Sometimes, you may have one or more derived files - already built in your local build tree - that you wish to make available to other people doing builds. - For example, you may find it more effective to perform - integration builds with the cache disabled - (per the previous section) - and only populate the shared cache directory - with the built files after the integration build - has completed successfully. - This way, the cache will only get filled up - with derived files that are part of a complete, successful build - not with files that might be later overwritten - while you debug integration problems. - - - - - - In this case, you can use the - the --cache-force option - to tell &SCons; to put all derived files in the cache, - even if the files already exist in your local tree - from having been built by a previous invocation: - - - - - % scons -Q --cache-disable - cc -o hello.o -c hello.c - cc -o hello hello.o - % scons -Q -c - Removed hello.o - Removed hello - % scons -Q --cache-disable - cc -o hello.o -c hello.c - cc -o hello hello.o - % scons -Q --cache-force - scons: `.' is up to date. - % scons -Q - scons: `.' is up to date. - - - - - Notice how the above sample run - demonstrates that the --cache-disable - option avoids putting the built - hello.o - and - hello files in the cache, - but after using the --cache-force option, - the files have been put in the cache - for the next invocation to retrieve. - - - -
- -
- Minimizing Cache Contention: the <literal>--random</literal> Option - - - - If you allow multiple builds to update the - shared cache directory simultaneously, - two builds that occur at the same time - can sometimes start "racing" - with one another to build the same files - in the same order. - If, for example, - you are linking multiple files into an executable program: - - - - - Program('prog', - ['f1.c', 'f2.c', 'f3.c', 'f4.c', 'f5.c']) - - - - - &SCons; will normally build the input object files - on which the program depends in their normal, sorted order: - - - - - % scons -Q - cc -o f1.o -c f1.c - cc -o f2.o -c f2.c - cc -o f3.o -c f3.c - cc -o f4.o -c f4.c - cc -o f5.o -c f5.c - cc -o prog f1.o f2.o f3.o f4.o f5.o - - - - - But if two such builds take place simultaneously, - they may each look in the cache at nearly the same - time and both decide that f1.o - must be rebuilt and pushed into the shared cache directory, - then both decide that f2.o - must be rebuilt (and pushed into the shared cache directory), - then both decide that f3.o - must be rebuilt... - This won't cause any actual build problems--both - builds will succeed, - generate correct output files, - and populate the cache--but - it does represent wasted effort. - - - - - - To alleviate such contention for the cache, - you can use the --random command-line option - to tell &SCons; to build dependencies - in a random order: - - - - - - - % scons -Q --random - cc -o f3.o -c f3.c - cc -o f1.o -c f1.c - cc -o f5.o -c f5.c - cc -o f2.o -c f2.c - cc -o f4.o -c f4.c - cc -o prog f1.o f2.o f3.o f4.o f5.o - - - - - Multiple builds using the --random option - will usually build their dependencies in different, - random orders, - which minimizes the chances for a lot of - contention for same-named files - in the shared cache directory. - Multiple simultaneous builds might still race to try to build - the same target file on occasion, - but long sequences of inefficient contention - should be rare. - - - - - - Note, of course, - the --random option - will cause the output that &SCons; prints - to be inconsistent from invocation to invocation, - which may be an issue when - trying to compare output from different build runs. - - - - - - If you want to make sure dependencies will be built - in a random order without having to specify - the --random on very command line, - you can use the &SetOption; function to - set the random option - within any &SConscript; file: - - - - - Program('prog', - ['f1.c', 'f2.c', 'f3.c', 'f4.c', 'f5.c']) - - SetOption('random', 1) - Program('prog', - ['f1.c', 'f2.c', 'f3.c', 'f4.c', 'f5.c']) - - -
- - - - diff --git a/doc/user/command-line.xml b/doc/user/command-line.xml index 148922eb..3d48b2a7 100644 --- a/doc/user/command-line.xml +++ b/doc/user/command-line.xml @@ -150,14 +150,14 @@ % scons - scons: Reading SConscript files ... + [?1034hscons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... ... [build output] ... scons: done building targets. % export SCONSFLAGS="-Q" % scons - ... [build output] ... + [?1034h ... [build output] ... @@ -309,7 +309,7 @@ % scons -Q - running with -j 2 + [?1034hrunning with -j 2 scons: `.' is up to date. @@ -324,7 +324,7 @@ % export NUM_CPU="4" % scons -Q - running with -j 4 + [?1034hrunning with -j 4 scons: `.' is up to date. @@ -341,11 +341,11 @@ % scons -Q -j 7 - running with -j 7 + [?1034hrunning with -j 7 scons: `.' is up to date. % export NUM_CPU="4" % scons -Q -j 3 - running with -j 3 + [?1034hrunning with -j 3 scons: `.' is up to date. @@ -630,7 +630,7 @@ % scons -Q -n - Install file: "foo.in" as "/usr/bin/foo.in" + [?1034hInstall file: "foo.in" as "/usr/bin/foo.in" @@ -643,7 +643,7 @@ % scons -Q -n --prefix=/tmp/install - Install file: "foo.in" as "/tmp/install/usr/bin/foo.in" + [?1034hInstall file: "foo.in" as "/tmp/install/usr/bin/foo.in" @@ -718,15 +718,14 @@ % scons -Q debug=0 - cc -o prog.o -c prog.c + [?1034hcc -o prog.o -c prog.c cc -o prog prog.o % scons -Q debug=0 - scons: `.' is up to date. + [?1034hscons: `.' is up to date. % scons -Q debug=1 - cc -o prog.o -c -g prog.c - cc -o prog prog.o + [?1034hscons: `.' is up to date. % scons -Q debug=1 - scons: `.' is up to date. + [?1034hscons: `.' is up to date. @@ -806,9 +805,9 @@ % scons -Q define=FOO - cc -o prog.o -c -DFOO prog.c + [?1034hcc -o prog.o -c -DFOO prog.c % scons -Q define=FOO define=BAR - cc -o prog.o -c -DFOO -DBAR prog.c + [?1034hscons: `.' is up to date. @@ -909,7 +908,7 @@ % scons -Q RELEASE=1 - cc -o bar.o -c -DRELEASE_BUILD=1 bar.c + [?1034hcc -o bar.o -c -DRELEASE_BUILD=1 bar.c cc -o foo.o -c -DRELEASE_BUILD=1 foo.c cc -o foo foo.o bar.o @@ -972,7 +971,7 @@ % scons -Q -h - + [?1034h RELEASE: Set to 1 to build for release default: 0 actual: 0 @@ -1037,7 +1036,7 @@ % scons -Q - cc -o bar.o -c -DRELEASE_BUILD=1 bar.c + [?1034hcc -o bar.o -c -DRELEASE_BUILD=1 bar.c cc -o foo.o -c -DRELEASE_BUILD=1 foo.c cc -o foo foo.o bar.o @@ -1061,7 +1060,7 @@ % scons -Q - cc -o bar.o -c -DRELEASE_BUILD=0 bar.c + [?1034hcc -o bar.o -c -DRELEASE_BUILD=0 bar.c cc -o foo.o -c -DRELEASE_BUILD=0 foo.c cc -o foo foo.o bar.o @@ -1127,12 +1126,12 @@ % scons -Q RELEASE=yes foo.o - cc -o foo.o -c -DRELEASE_BUILD=True foo.c + [?1034hcc -o foo.o -c -DRELEASE_BUILD=True foo.c % scons -Q RELEASE=t foo.o - cc -o foo.o -c -DRELEASE_BUILD=True foo.c + [?1034hcc -o foo.o -c -DRELEASE_BUILD=True foo.c @@ -1158,12 +1157,12 @@ % scons -Q RELEASE=no foo.o - cc -o foo.o -c -DRELEASE_BUILD=False foo.c + [?1034hcc -o foo.o -c -DRELEASE_BUILD=False foo.c % scons -Q RELEASE=f foo.o - cc -o foo.o -c -DRELEASE_BUILD=False foo.c + [?1034hcc -o foo.o -c -DRELEASE_BUILD=False foo.c @@ -1190,7 +1189,8 @@ scons: *** Error converting option: RELEASE Invalid value for boolean option: bad_value - File "/home/my/project/SConstruct", line 4, in <module> + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Variables\__init__.py", line 214, in Update + [?1034h @@ -1233,11 +1233,11 @@ % scons -Q COLOR=red foo.o - cc -o foo.o -c -DCOLOR="red" foo.c + [?1034hcc -o foo.o -c -DCOLOR="red" foo.c % scons -Q COLOR=blue foo.o - cc -o foo.o -c -DCOLOR="blue" foo.c + [?1034hscons: `foo.o' is up to date. % scons -Q COLOR=green foo.o - cc -o foo.o -c -DCOLOR="green" foo.c + [?1034hscons: `foo.o' is up to date. @@ -1253,7 +1253,8 @@ % scons -Q COLOR=magenta foo.o scons: *** Invalid value for option COLOR: magenta - File "/home/my/project/SConstruct", line 5, in <module> + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Variables\EnumVariable.py", line 51, in _validator + [?1034h @@ -1292,7 +1293,7 @@ % scons -Q COLOR=navy foo.o - cc -o foo.o -c -DCOLOR="blue" foo.c + [?1034hcc -o foo.o -c -DCOLOR="blue" foo.c @@ -1309,15 +1310,18 @@ % scons -Q COLOR=Red foo.o scons: *** Invalid value for option COLOR: Red - File "/home/my/project/SConstruct", line 5, in <module> + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Variables\EnumVariable.py", line 51, in _validator + [?1034h % scons -Q COLOR=BLUE foo.o scons: *** Invalid value for option COLOR: BLUE - File "/home/my/project/SConstruct", line 5, in <module> + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Variables\EnumVariable.py", line 51, in _validator + [?1034h % scons -Q COLOR=nAvY foo.o scons: *** Invalid value for option COLOR: nAvY - File "/home/my/project/SConstruct", line 5, in <module> + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Variables\EnumVariable.py", line 51, in _validator + [?1034h @@ -1349,13 +1353,13 @@ % scons -Q COLOR=Red foo.o - cc -o foo.o -c -DCOLOR="Red" foo.c + [?1034hcc -o foo.o -c -DCOLOR="Red" foo.c % scons -Q COLOR=BLUE foo.o - cc -o foo.o -c -DCOLOR="BLUE" foo.c + [?1034hscons: `foo.o' is up to date. % scons -Q COLOR=nAvY foo.o - cc -o foo.o -c -DCOLOR="blue" foo.c + [?1034hscons: `foo.o' is up to date. % scons -Q COLOR=green foo.o - cc -o foo.o -c -DCOLOR="green" foo.c + [?1034hscons: `foo.o' is up to date. @@ -1393,11 +1397,11 @@ % scons -Q COLOR=Red foo.o - cc -o foo.o -c -DCOLOR="red" foo.c + [?1034hcc -o foo.o -c -DCOLOR="red" foo.c % scons -Q COLOR=nAvY foo.o - cc -o foo.o -c -DCOLOR="blue" foo.c + [?1034hscons: `foo.o' is up to date. % scons -Q COLOR=GREEN foo.o - cc -o foo.o -c -DCOLOR="green" foo.c + [?1034hscons: `foo.o' is up to date. @@ -1436,9 +1440,9 @@ % scons -Q COLORS=red,blue foo.o - cc -o foo.o -c -DCOLORS="red blue" foo.c + [?1034hcc -o foo.o -c -DCOLORS="red blue" foo.c % scons -Q COLORS=blue,green,red foo.o - cc -o foo.o -c -DCOLORS="blue green red" foo.c + [?1034hscons: `foo.o' is up to date. @@ -1453,9 +1457,9 @@ % scons -Q COLORS=all foo.o - cc -o foo.o -c -DCOLORS="red green blue" foo.c + [?1034hcc -o foo.o -c -DCOLORS="red green blue" foo.c % scons -Q COLORS=none foo.o - cc -o foo.o -c -DCOLORS="" foo.c + [?1034hscons: `foo.o' is up to date. @@ -1470,7 +1474,8 @@ scons: *** Error converting option: COLORS Invalid value(s) for option: magenta - File "/home/my/project/SConstruct", line 5, in <module> + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Variables\__init__.py", line 214, in Update + [?1034h @@ -1510,9 +1515,9 @@ % scons -Q foo.o - cc -o foo.o -c -DCONFIG_FILE="/etc/my_config" foo.c + [?1034hcc -o foo.o -c -DCONFIG_FILE="/etc/my_config" foo.c % scons -Q CONFIG=/usr/local/etc/other_config foo.o - scons: `foo.o' is up to date. + [?1034hscons: `foo.o' is up to date. @@ -1527,7 +1532,8 @@ % scons -Q CONFIG=/does/not/exist foo.o scons: *** Path for option CONFIG does not exist: /does/not/exist - File "/home/my/project/SConstruct", line 6, in <module> + File "p:\cyghome\bdeegan\scons\trunk\bootstrap\src\engine\SCons\Variables\PathVariable.py", line 117, in PathExists + [?1034h @@ -1655,13 +1661,13 @@ % scons -Q foo.o - cc -o foo.o -c -DPACKAGE="/opt/location" foo.c + [?1034hcc -o foo.o -c -DPACKAGE="/opt/location" foo.c % scons -Q PACKAGE=/usr/local/location foo.o - cc -o foo.o -c -DPACKAGE="/usr/local/location" foo.c + [?1034hscons: `foo.o' is up to date. % scons -Q PACKAGE=yes foo.o - cc -o foo.o -c -DPACKAGE="True" foo.c + [?1034hscons: `foo.o' is up to date. % scons -Q PACKAGE=no foo.o - cc -o foo.o -c -DPACKAGE="False" foo.c + [?1034hscons: `foo.o' is up to date. @@ -1781,7 +1787,7 @@ % scons -Q NOT_KNOWN=foo - Unknown variables: ['NOT_KNOWN'] + [?1034hUnknown variables: ['NOT_KNOWN'] @@ -1849,10 +1855,10 @@ % scons -Q - cc -o foo.o -c foo.c + [?1034hcc -o foo.o -c foo.c cc -o foo foo.o % scons -Q bar - Don't forget to copy `bar' to the archive! + [?1034hDon't forget to copy `bar' to the archive! cc -o bar.o -c bar.c cc -o bar bar.o @@ -1908,12 +1914,12 @@ % scons -Q - cc -o hello.o -c hello.c + [?1034hcc -o hello.o -c hello.c cc -o hello hello.o % scons -Q - scons: `hello' is up to date. + [?1034hscons: `hello' is up to date. % scons -Q goodbye - cc -o goodbye.o -c goodbye.c + [?1034hcc -o goodbye.o -c goodbye.c cc -o goodbye goodbye.o @@ -1930,7 +1936,7 @@ % scons -Q . - cc -o goodbye.o -c goodbye.c + [?1034hcc -o goodbye.o -c goodbye.c cc -o goodbye goodbye.o cc -o hello.o -c hello.c cc -o hello hello.o @@ -1982,12 +1988,12 @@ % scons -Q - cc -o prog1.o -c prog1.c + [?1034hcc -o prog1.o -c prog1.c cc -o prog1 prog1.o cc -o prog3.o -c prog3.c cc -o prog3 prog3.o % scons -Q . - cc -o prog2.o -c prog2.c + [?1034hcc -o prog2.o -c prog2.c cc -o prog2 prog2.o @@ -2014,13 +2020,13 @@ % scons -Q - cc -o prog1/foo.o -c prog1/foo.c + [?1034hcc -o prog1/foo.o -c prog1/foo.c cc -o prog1/main.o -c prog1/main.c cc -o prog1/main prog1/main.o prog1/foo.o % scons -Q - scons: `prog1' is up to date. + [?1034hscons: `prog1' is up to date. % scons -Q . - cc -o prog2/bar.o -c prog2/bar.c + [?1034hcc -o prog2/bar.o -c prog2/bar.c cc -o prog2/main.o -c prog2/main.c cc -o prog2/main prog2/main.o prog2/bar.o @@ -2050,8 +2056,9 @@ % scons -Q scons: *** No targets specified and no Default() targets found. Stop. + [?1034h % scons -Q . - cc -o prog1.o -c prog1.c + [?1034hcc -o prog1.o -c prog1.c cc -o prog1 prog1.o cc -o prog2.o -c prog2.c cc -o prog2 prog2.o @@ -2094,7 +2101,7 @@ % scons - scons: Reading SConscript files ... + [?1034hscons: Reading SConscript files ... DEFAULT_TARGETS is ['prog1'] scons: done reading SConscript files. scons: Building targets ... @@ -2129,7 +2136,7 @@ % scons - scons: Reading SConscript files ... + [?1034hscons: Reading SConscript files ... DEFAULT_TARGETS is now ['prog1'] DEFAULT_TARGETS is now ['prog1', 'prog2'] scons: done reading SConscript files. @@ -2224,15 +2231,15 @@ % scons -Q - BUILD_TARGETS is ['prog1'] + [?1034hBUILD_TARGETS is ['prog1'] cc -o prog1.o -c prog1.c cc -o prog1 prog1.o % scons -Q prog2 - BUILD_TARGETS is ['prog2'] + [?1034hBUILD_TARGETS is ['prog2'] cc -o prog2.o -c prog2.c cc -o prog2 prog2.o % scons -Q -c . - BUILD_TARGETS is ['.'] + [?1034hBUILD_TARGETS is ['.'] Removed prog1.o Removed prog1 Removed prog2.o diff --git a/doc/user/depends.xml b/doc/user/depends.xml index c9207d56..873c5f17 100644 --- a/doc/user/depends.xml +++ b/doc/user/depends.xml @@ -347,6 +347,7 @@ % touch -t 198901010000 hello.c % scons -Q hello.o cc -o hello.o -c hello.c + cc -o hello hello.o @@ -986,6 +987,12 @@ C:\>scons -Q hello.exe + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Fohello.obj /c hello.c /nologo /Iinclude /I\home\project\inc link /nologo /OUT:hello.exe hello.obj @@ -1650,17 +1657,15 @@ % scons -Q hello cc -o version.o -c version.c - cc -o hello.o -c hello.c - cc -o hello version.o hello.o - % sleep 1 - % scons -Q hello cc -o version.o -c version.c + cc -o hello.o -c hello.c scons: `hello' is up to date. % sleep 1 % edit hello.c [CHANGE THE CONTENTS OF hello.c] % scons -Q hello cc -o version.o -c version.c + cc -o version.o -c version.c cc -o hello.o -c hello.c cc -o hello version.o hello.o % sleep 1 diff --git a/doc/user/environments.xml b/doc/user/environments.xml index 0746793b..f81dac7b 100644 --- a/doc/user/environments.xml +++ b/doc/user/environments.xml @@ -656,6 +656,18 @@ environment, of directory names, suffixes, etc. C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ key = OBJSUFFIX, value = .obj key = LIBSUFFIX, value = .lib key = PROGSUFFIX, value = .exe @@ -951,8 +963,15 @@ environment, of directory names, suffixes, etc. % scons -Q - scons: *** Two environments with different actions were specified for the same target: foo.o - File "/home/my/project/SConstruct", line 6, in <module> + scons: warning: Two different environments were specified for target foo.o, + but they appear to have the same action: CCCom(target, source, env) + File "/home/my/project/SConstruct", line 6, in ? + + scons: warning: Two different environments were specified for target foo, + but they appear to have the same action: Cat(target, source, env) + File "/home/my/project/SConstruct", line 6, in ? + cc -o foo.o -c -g foo.c + cc -o foo foo.o diff --git a/doc/user/less-simple.xml b/doc/user/less-simple.xml index 0bc382ef..e7db86da 100644 --- a/doc/user/less-simple.xml +++ b/doc/user/less-simple.xml @@ -100,6 +100,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Fohello.obj /c hello.c /nologo link /nologo /OUT:new_hello.exe hello.obj @@ -189,6 +195,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Fofile1.obj /c file1.c /nologo cl /Fofile2.obj /c file2.c /nologo cl /Foprog.obj /c prog.c /nologo diff --git a/doc/user/libraries.xml b/doc/user/libraries.xml index 1fa06af9..45ad16a7 100644 --- a/doc/user/libraries.xml +++ b/doc/user/libraries.xml @@ -73,6 +73,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Fof1.obj /c f1.c /nologo cl /Fof2.obj /c f2.c /nologo cl /Fof3.obj /c f3.c /nologo @@ -201,6 +207,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Fof1.obj /c f1.c /nologo cl /Fof2.obj /c f2.c /nologo cl /Fof3.obj /c f3.c /nologo @@ -282,6 +294,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Fof1.obj /c f1.c /nologo cl /Fof2.obj /c f2.c /nologo cl /Fof3.obj /c f3.c /nologo @@ -410,6 +428,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Foprog.obj /c prog.c /nologo link /nologo /OUT:prog.exe /LIBPATH:\usr\lib /LIBPATH:\usr\local\lib m.lib prog.obj diff --git a/doc/user/nodes.xml b/doc/user/nodes.xml index 8f3436a4..394ec372 100644 --- a/doc/user/nodes.xml +++ b/doc/user/nodes.xml @@ -128,6 +128,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Fogoodbye.obj /c goodbye.c -DGOODBYE cl /Fohello.obj /c hello.c -DHELLO link /nologo /OUT:hello.exe hello.obj goodbye.obj @@ -271,6 +277,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ The object file is: hello.obj The program file is: hello.exe cl /Fohello.obj /c hello.c /nologo diff --git a/doc/user/output.xml b/doc/user/output.xml index ff39fca0..8a9b67e4 100644 --- a/doc/user/output.xml +++ b/doc/user/output.xml @@ -132,6 +132,18 @@ C:\>scons -h scons: Reading SConscript files ... + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ scons: done reading SConscript files. Type: 'scons program' to build the production program. diff --git a/doc/user/parseconfig.xml b/doc/user/parseconfig.xml index 3613d77c..4adf97d2 100644 --- a/doc/user/parseconfig.xml +++ b/doc/user/parseconfig.xml @@ -89,8 +89,17 @@ % scons -Q - ['/lib/compat', '/usr/X11/include'] - scons: `.' is up to date. + Package x11 was not found in the pkg-config search path. + Perhaps you should add the directory containing `x11.pc' + to the PKG_CONFIG_PATH environment variable + No package 'x11' found + OSError: 'pkg-config x11 --cflags --libs' exited 1: + File "/home/my/project/SConstruct", line 3: + env.ParseConfig("pkg-config x11 --cflags --libs") + File "bootstrap/src/engine/SCons/Environment.py", line 1474: + None + File "bootstrap/src/engine/SCons/Environment.py", line 593: + None @@ -131,6 +140,15 @@ % scons -Q - ['/usr/X11/include'] - scons: `.' is up to date. + Package x11 was not found in the pkg-config search path. + Perhaps you should add the directory containing `x11.pc' + to the PKG_CONFIG_PATH environment variable + No package 'x11' found + OSError: 'pkg-config x11 --cflags --libs' exited 1: + File "/home/my/project/SConstruct", line 2: + env.ParseConfig("pkg-config x11 --cflags --libs") + File "bootstrap/src/engine/SCons/Environment.py", line 1474: + None + File "bootstrap/src/engine/SCons/Environment.py", line 593: + None diff --git a/doc/user/parseflags.xml b/doc/user/parseflags.xml index 632077e5..1a169ac2 100644 --- a/doc/user/parseflags.xml +++ b/doc/user/parseflags.xml @@ -88,6 +88,18 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ CPPPATH ['/opt/include'] LIBPATH ['/opt/lib'] LIBS ['foo'] diff --git a/doc/user/simple.xml b/doc/user/simple.xml index 6bd70b0b..30898546 100644 --- a/doc/user/simple.xml +++ b/doc/user/simple.xml @@ -106,6 +106,12 @@ C:\>scons scons: Reading SConscript files ... + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ scons: done reading SConscript files. scons: Building targets ... cl /Fohello.obj /c hello.c /nologo @@ -193,6 +199,12 @@ C:\>scons scons: Reading SConscript files ... + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ scons: done reading SConscript files. scons: Building targets ... cl /Fohello.obj /c hello.c /nologo @@ -296,6 +308,12 @@ C:\>scons scons: Reading SConscript files ... + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ scons: done reading SConscript files. scons: Building targets ... cl /Fohello.obj /c hello.c /nologo @@ -303,6 +321,12 @@ scons: done building targets. C:\>scons -c scons: Reading SConscript files ... + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ scons: done reading SConscript files. scons: Cleaning targets ... Removed hello.obj @@ -503,6 +527,12 @@ C:\>scons scons: Reading SConscript files ... + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ scons: done reading SConscript files. scons: Building targets ... cl /Fohello.obj /c hello.c /nologo @@ -534,6 +564,12 @@ C:\>scons -Q + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ cl /Fohello.obj /c hello.c /nologo link /nologo /OUT:hello.exe hello.obj diff --git a/doc/user/troubleshoot.xml b/doc/user/troubleshoot.xml index 857fcc3e..2ac91ec2 100644 --- a/doc/user/troubleshoot.xml +++ b/doc/user/troubleshoot.xml @@ -341,6 +341,18 @@ C:\>scons scons: Reading SConscript files ... + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ { 'BUILDERS': {'_InternalInstall': <function InstallBuilderWrapper at 0x700000>, 'Object': <SCons.Builder.CompositeBuilder instance at 0x700000>, 'PCH': <SCons.Builder.BuilderBase instance at 0x700000>, 'RES': <SCons.Builder.BuilderBase instance at 0x700000>, 'SharedObject': <SCons.Builder.CompositeBuilder instance at 0x700000>, 'StaticObject': <SCons.Builder.CompositeBuilder instance at 0x700000>, '_InternalInstallAs': <function InstallAsBuilderWrapper at 0x700000>}, 'CC': 'cl', 'CCCOM': <SCons.Action.FunctionAction instance at 0x700000>, @@ -379,7 +391,7 @@ 'DSUFFIXES': ['.d'], 'Dir': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>, 'Dirs': <SCons.Defaults.Variable_Method_Caller instance at 0x700000>, - 'ENV': { 'PATH': 'C:\\WINDOWS\\System32', + 'ENV': { 'PATH': 'C:/WINDOWS\\System32', 'PATHEXT': '.COM;.EXE;.BAT;.CMD', 'SystemRoot': 'C:\\WINDOWS'}, 'ESCAPE': <function escape at 0x700000>, @@ -505,7 +517,18 @@ C:\>scons scons: Reading SConscript files ... - { 'PATH': 'C:\\WINDOWS\\System32', + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ + { 'PATH': 'C:/WINDOWS\\System32', 'PATHEXT': '.COM;.EXE;.BAT;.CMD', 'SystemRoot': 'C:\\WINDOWS'} scons: done reading SConscript files. @@ -1121,11 +1144,8 @@ File "bootstrap/src/engine/SCons/Job.py", line 197, in start task.prepare() File "bootstrap/src/engine/SCons/Script/Main.py", line 167, in prepare - return SCons.Taskmaster.OutOfDateTask.prepare(self) File "bootstrap/src/engine/SCons/Taskmaster.py", line 190, in prepare - executor.prepare() File "bootstrap/src/engine/SCons/Executor.py", line 397, in prepare - raise SCons.Errors.StopError, msg % (s, self.batches[0].targets[0]) diff --git a/doc/user/variants.xml b/doc/user/variants.xml index 3ae3e4a8..e60dd8c2 100644 --- a/doc/user/variants.xml +++ b/doc/user/variants.xml @@ -108,6 +108,18 @@ is pretty smart about rebuilding things when you change options. C:\>scons -Q OS=windows + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ + + scons: warning: No installed VCs + File "<stdin>", line 67, in __call__ + + scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly + File "<stdin>", line 67, in __call__ Install file: "build/windows/world/world.h" as "export/windows/include/world.h" cl /Fobuild\windows\hello\hello.obj /c build\windows\hello\hello.c /nologo /Iexport\windows\include cl /Fobuild\windows\world\world.obj /c build\windows\world\world.c /nologo /Iexport\windows\include diff --git a/src/RELEASE.txt b/src/RELEASE.txt index b9c9fc87..843fab28 100644 --- a/src/RELEASE.txt +++ b/src/RELEASE.txt @@ -20,7 +20,7 @@ more effectively, please sign up for the scons-users mailing list at: -RELEASE 1.2.0.d20090223 - Mon, 23 Feb 2009 08:41:06 -0800 +RELEASE 1.2.0.d20100117 - Sun, 17 Jan 2010 14:26:59 -0800 Please consult the CHANGES.txt file for a list of specific changes since last release. @@ -34,7 +34,7 @@ RELEASE 1.2.0.d20090223 - Mon, 23 Feb 2009 08:41:06 -0800 features will still be supported in 1.3.0 but will generate mandatory, non-disableable warnings: - -- Support for Python versions 1.5, 1.6, 2.0, 2.1, 2.2 and 2.3. + -- Support for Python versions 1.5, 1.6, 2.0, 2.1, 2.2, and 2.3. -- The overrides= keyword argument to the Builder() call. -- The scanner= keyword argument to the Builder() call. -- The BuildDir() function and env.BuildDir() method. @@ -80,6 +80,13 @@ RELEASE 1.2.0.d20090223 - Mon, 23 Feb 2009 08:41:06 -0800 projects from your SConstructs, MSVS_VERSION must be set to the same version as MSVC_VERSION. + Support for HOST_OS,HOST_ARCH,TARGET_OS, TARGET_ARCH has been + added to allow specifying different target arch than the host + system. This is only supported for Visual Studio/Visual C++ + at this time. + + -- Support for Latex glosseries and acronyms has been added + -- VISUAL C/C++ PRECOMPILED HEADERS WILL BE REBUILT Precompiled header files built with Visual C/C++ will be