diff options
Diffstat (limited to 'src/boost/tools/build/notes')
| -rw-r--r-- | src/boost/tools/build/notes/README.txt | 8 | ||||
| -rw-r--r-- | src/boost/tools/build/notes/build_dir_option.txt | 77 | ||||
| -rw-r--r-- | src/boost/tools/build/notes/changes.txt | 317 | ||||
| -rw-r--r-- | src/boost/tools/build/notes/relative_source_paths.txt | 76 | ||||
| -rw-r--r-- | src/boost/tools/build/notes/release_procedure.txt | 83 |
5 files changed, 561 insertions, 0 deletions
diff --git a/src/boost/tools/build/notes/README.txt b/src/boost/tools/build/notes/README.txt new file mode 100644 index 00000000..96ef0c3a --- /dev/null +++ b/src/boost/tools/build/notes/README.txt @@ -0,0 +1,8 @@ +Copyright 2005 Vladimir Prus +Distributed under the Boost Software License, Version 1.0. +(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt) + + +This directory contains various development notes. Some of them +may eventually find the way into documentation, so are purely +implementation comments. diff --git a/src/boost/tools/build/notes/build_dir_option.txt b/src/boost/tools/build/notes/build_dir_option.txt new file mode 100644 index 00000000..6dbecaed --- /dev/null +++ b/src/boost/tools/build/notes/build_dir_option.txt @@ -0,0 +1,77 @@ +Copyright 2005 Vladimir Prus +Distributed under the Boost Software License, Version 1.0. +(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt) + + +Summary +------- + +We need a --build-dir option that users building from read-only +medium can use to force building to some other location. Pretty much +every project need this functionality, so it's desirable to have it +out-of-the box, without explicit setup. + +Design +------ + +We can achieve the desired effect manually by adding something like this +to Jamroot: + + project .... : build-dir [ my-rule-to-compute-build-dir ] ; + +Where 'my-rule-to-compute-build-dir' would look at the --build-dir option. + +We need to automate this, but essentially, --build-dir will only affect +the 'build-dir' attribute of Jamroots. + +If Jamroot contains: + + project foo ; + +and --build-dir options' value if /tmp/build, then we'll act as if Jamroot +contained: + + project foo : build-dir /tmp/build/foo ; + +If the 'project' rule has explicit 'build-dir': + + project foo : build-dir bin.v2 ; + +then with the same value of --build-dir we'd act as if Jamroot contained: + + project foo : build-dir /tmp/build/foo/bin.v2 ; + +We can't drop "bin.v2" because it's quite possible that the name of build dir +have specific meaning. For example, it can be used to separate Boost.Build V1 +and V2 build results. + +The --build-dir option has no effect if Jamroot does not define any project id. +Doing otherwise can lead to nasty problems if we're building two distinct +projects (that is with two different Jamroot). They'll get the same build +directory. Most likely, user will see the "duplicate target" error, which is +generally confusing. + +It is expected that any non-trivial project will have top-level "project" +invocation with non empty id, so the above limitation is not so drastic. +We'll emit a warning if Jamroot does not define project id, and --build-dir +is specified. + +Here's the exact behavior of the --build-dir option. If we're loading a +Jamfile (either root or non-root), that declare some project id and some +build-dir attribute, the following table gives the value of build-dir +that will actually be used. + +------------------------------------------------------------------------------- +Root? Id Build-dir attribute Resulting build dir +------------------------------------------------------------------------------- +yes none * --build-dir is ignored, with warning +yes 'foo' none /tmp/build/foo +yes 'foo' 'bin.v2' /tmp/build/foo/bin.v2 +yes 'foo' '/tmp/bar' Error [1] +no * none --build-dir has no effect, inherited + build dir is used +no * non-empty Error [2] +------------------------------------------------------------------------------- +[1] -- not clear what to do +[2] -- can be made to work, but non-empty build-dir +attribute in non-root Jamfile does not make much sense even without --build-dir diff --git a/src/boost/tools/build/notes/changes.txt b/src/boost/tools/build/notes/changes.txt new file mode 100644 index 00000000..bb98661f --- /dev/null +++ b/src/boost/tools/build/notes/changes.txt @@ -0,0 +1,317 @@ +Copyright 2004-2007 Vladimir Prus +Distributed under the Boost Software License, Version 1.0. +(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt) + +Milestone 13 (in development) + +Changes in this release: + +The following bugs were fixed: + + - gcc support did not work on HP-UX systems + +Milestone 12 (Oct 1, 2007) + +Changes in this release: + + - The Pathscale, PGI and mipspro compilers are now supported. + - Support for autoconfiguration of toolset based on command-line + toolset=xxxx request, and for default toolset + configuration as a fallback. + - Support for precompiled headers for gcc toolset, + and improvements for msvc. + - Mechanism for removing inherited requirements. + - The 'make' rule support specifying usage-requirements. + - New 'project.extension' rule for declaring standalone + projects. + - New 'conditional' convenience rule. + - New 'glob-tree' rule. + - The 'glob' rule accepts patterns to exclude. + - Inline targets are now marked explicit automatically. + - Toolsets can now implicitly add requirements to + all targets. + - New 'generate' rule. + - The executables produced by the 'run' rule are automatically + removed after run. + - The gcc toolset uses the version obtained by running + the compiler, if no explicit one is provided. + - The sun toolset now supports the 'address-model' feature, + and uses -KPIC for shared libraries. + - Free features on command line affect all targets, not + just 'directly requested' ones. + + +Documentation changes: + + - Installation instructions for Linux distributors. + - Configuration options for all supported C++ compilers + are now documented. + +The following bugs were fixed: + + - The 'cflags' and 'linkflags' now work on Darwin.o + - The intel toolset now works on Windows. + - Fix library search options for CodeWarriour toolset. + - The <install-source-root> could cause duplicate + mkdir commands. + - Numerious fixes in Boost autolink support + - Numerious fixes in Boost.Python support. + - Indirect properties not evaluated in usage requirements. + - Generator that returns a property set but not target is + considered successful. + - On Darwin, when several compiler versions + are configured, -fcoalesce-templates is applied only to + versions that need it. + + +Milestone 11 (Jule 20, 2006) + +Changes in this release: + + - New C++ compilers: IBM xlf, HP aCC, HP CXX, Intel fortran compiler. + - New tools: Qt4 support, MS message compiler and IDL compiler. + - New main targets: 'notfile' and 'cast'. + + - Core changes: + + - Only one file required at top level of a project, named Jamroot. + - Jamfiles can now contain project-specific help messages. + - "Indirect conditional requirements" introduced + (http://tinyurl.com/mn3jp) + - Strip suffix in main target names when computing names of generated + files (URL) + - The 'source-location' project attribute can contain + several directories. + - Usage requirements are propagated not only direct dependents, + but to indirect dependents. + + - Command line option changes (see http://tinyurl.com/zbycz) + - New option --build-dir + - The --clean option cleans only target below the current directory, + not globally. + - New --clean-all option was added. + - New option --debug-building + - Running "bjam some_directory" works even if there's no Jamfile + in the current directory. + + - Toolset improvements: + - Assembling support with gcc, borland and msvc. + - Support amd64/ia64 cross-compiling with msvc. + - Improved, registry-based autodetection for msvc. + - Serialize execution of gcc.link actions + - Precompiled headers supported on MSVC + (Need documentation) + + - New features <warnings> and <warnings-as-errors> + - The 'glob' rule accepts wildcards in directory names. + - The 'stage' rule was renamed to 'install' + (the old name still available for compatibility) + - The <tag> feature can accept user-defined function as value + (URL) + - The 'install' rule can install a directory hierarchy preserving relative + paths. + - The 'install' rule no longer allows to change library + name during install. + - The Jamfile referred via 'use-project' may declare project id different + from the one in 'use-project'. + - The 'using' rule now searches the directory of containing Jamfile. + + +The following bugs were fixed: + + - The <library> feature was ignored for static linking + - Fix #include scanning for C files. + - Child projects were sometimes loaded before parent projects. + - Fix project references with absolute paths on Windows. + - The <dependency> feature was ignored for 'install' targets. + - A generator having the same type in sources and targets was causing hang. + - Use 'icpc' command for Intel, fixing errors with 8.1 and higher. + - Generation of PS files with the FOP tool really produces .PS files. + - No dependency scanning was done for C files. + - The 'constant' and 'path-constant' rules did not accept multi-element + value. + - Don't pass -fcoalesce-templates to gcc on OSX 10.4 + - Fix static lib suffix on OSX. + - Fix rpath setting on Intel/Linux. + - The 'install' rule don't unnecessary scans #includes in installed + headers. + + +Developer visible changes: + + - Ability to customize type's prefix depending on build properties. + - Generator's 'run' method can return usage-requirements. + - Main target rule is automatically declared for each new target type. + - 'Link incompatible' feature attribute was removed + - Generators no longer bypass unhandled sources, they just ignore them. + - If there are several applicable generators, immediately report ambiguity. + Provide a way to explicitly resolve conflicts between generators. + - The 'flags' rule can match absence of feature. + - Great improvement in response files handling + - The 'toolset.flags' rules allows value-less feature to signify + absence of this feature (fix hack-hack). + - Automatically declare main target rule for each declared target type. + - When inheriting types, inherit generators for the base type, as opposed + to using various hacks to invoke base generators when needed. + - Improve diagnostic for "duplicate actual target" and generator ambiguity. + + +Milestone 10 (October 29, 2004) + +Changes in this release: + + Many toolsets were added: Intel, Metrowerks, Comeau, aCC, vacpp. + Documentation was converted to BoostBook and improved. + Performance was improved. + + - Toolsets initialization syntax is much more uniform. Compiler and linker + flags can now be specified. + - The algorithm for computing build properties was improved. Conditional + requirements can be chained, and a number of bugs were fixed. + - Specific order of properties can be specified. + - The main target rules can be called from everywhere, not necessary from + Jamfile. + - Check for "unused sources" removed. + - The <library> feature affects only linking now. + - The <file> feature now works only for libraries. + - Simpler syntax for "searched" libraries was added. + - New <dependency> feature. + + + Unix: + The right order of static libraries on Unix is automatically + computed. + The <hardcode-dll-paths> feature is the default. + gcc: + The -fPIC option is passed when creating shared libraries. + Problems with distcc were solved. + Sun: + It's now possible to use the sun linker (as opposed to gnu), and + to compile C files. + Darwin: + Shared libraries are now supported. + MSVC: Before resource files compilation, the setup script is invoked. + Options deprecated in 8.0 are not longer used. + + +The following bugs were fixed: + + - The <unit-test> rule did not handle the <library> property (!!!!!!) + - Don't add "bin" to the build directory explicitly specified by the user. + - Allow <include-type> to select staged targets, + even with <traverse-dependencies>off. + - Includes for the form '# include <whatever>" did not work. + - (Qt) Add paths to all dependent libs to uic command + line, which helps if the UI files uses plugins. + - Using <toolset-msvc:version>xxx in requirements was broken. + - Error message printed when target can be found is much more clear. + - Inline targets in sources of 'stage' did not work. + - Don't produce 'independent target' warnings on Windows + - (gcc) The <link-runtime>static did not work. + - (gcc) Suppress warnings from the 'ar' tool on some systems. + - (gcc) Don't try to set soname on NT. + +Developer visible changes: + + - Generator priorities are gone, explicit overrides are used. + - 'Active' features were removed + - Support for VMS paths was added. + +Thanks to Christopher Currie, Pedro Ferreira, Philipp Frauenfelder, +Andre Hentz, Jurgen Hunold, Toon Knapen, Johan Nilsson, Alexey Pakhunov, +Brock Peabody, Michael Stevens and Zbynek Winkler who contributed +code to this release. + + +Milestone 9.1 (Nov 6, 2003) + +The following bugs were fixed: + + - The 'unit-test' rule used to ignore <library> properties. + - The gcc toolset used to ignore <threading> property. + +Milestone 9 (Nov 6, 2003) + +Changes in this release + + - Putting library in sources of other library now works even for static + linking, which makes expressing library->library dependency much + simpler. + - Performance was considerably improved. + - Regression testing framework now works on windows. + - The "alias" rule can have usage requirements and passes on usage + requirements of sources. + - The "stage" rule can traverse dependencies. + - Support for "def files" was implemented. + - Targets paths are now shorter. + - Darwin toolset was improved. + +The following bugs were fixed: + + - It was not possible to specify empty suffix for a target type derived + from other type. + - The stage rules used to generate incorrect suffix in some cases. + - It was possible to load Jamfile twice. + - The 'use-project' rule was broken when referring to a child project. + - Use of composite properties in requirements did not work. + +Developer visible changes: + + - New CALC builtin, which considerable improves performance. + - Source layout was reorganized. + - Handling of response file was simplified. + +Thanks to Pedro Ferreira, Kirill Lapshin, Andre Hentz, Paul Lin, +Jurgen Hunold, Christopher Currie, and Brock Peabody, who contributed to +this release. + +Milestone 8 (Oct 15, 2003) + +Changes in this release: + + - A regression testing framework was implemented. + - New <implicit-dependency> feature was added for better handling + of dependencies to generated headers. + - The link-compatibility checks not longer cause projects to be skipped, + and issue warning, not error, for main targets. + - Algorithm for selecting main target alternative was improved. + - The <dependency> feature was renamed to <use>. + - Project root constants were made available in project root itself. + +The following bugs were fixed: + + - failure to recognize shared libraries with version as such + - the 'path-constant' rule was mishandling absolute paths on Windows. + + +Milestone 7 (Sep 11, 2003) + +Changes in this release: + + - Performance was improved. + - Support for Sun and Darwin toolsets was added. + - <tag> feature, which changes the name of target depending of build + variant, was implemented. + - Old-style targets-ids are no longer supported. + - New 'glob' rule allows to easily perform wildcard matching in Jamfile. + - Improve bison/flex support to understand C++. + +The following bugs were fixed: + + - bogus error on use of project default-build attribute with several + main target alternatives. + - broken toolset inheritance + - hard error after skipping a target due to incompatible requirements + - incorrect behaviour of a generator when producing several targets of + the same type + - errors on use of the 'project-root' rule in Jamfile context + - inability to require specific compiler version for a main target. + - incorrect behaviour of "bjam msvc" when msvc is configured with explicit + version. + +Thanks to Christopher Currie, Pedro Ferreira and Michael Stevens, who +contributed to this release. + + + + diff --git a/src/boost/tools/build/notes/relative_source_paths.txt b/src/boost/tools/build/notes/relative_source_paths.txt new file mode 100644 index 00000000..2f055789 --- /dev/null +++ b/src/boost/tools/build/notes/relative_source_paths.txt @@ -0,0 +1,76 @@ +Copyright 2005 Vladimir Prus +Distributed under the Boost Software License, Version 1.0. +(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt) + + +Hi, +recently, we had a couple of problems caused by using relative file paths, and +I'd like to discuss what to do. + +Let's use the case from CÊdric. Simplified version is: + + exe a : a.cpp dir1/qt_file.h ; + exe b : a.cpp dir2/qt_file.h ; + +Both exes have the same source cpp file but different *.h files -- which are +processed by Qt tools. V2 currently strips directory name from all targets, +so it tries to + + - create "bin/mvsc/debug/moc_qt_file.cpp" from dir1/qt_file.h + - create "bin/msvc/debug/moc_qt_file.cpp" from dir2/qt_file.h + +There are two solutions that I see: + + 1. Rewrite the code like: + + lib aux : a.cpp + exe a : aux dir1/qt_file.h : <location-prefix>a ; + exe b : aux dir2/qt_file.h : <location-prefix>b ; + + This way, two version of moc_qt_file.cpp will be generated to different + places. + + 2. Rewrite the code like: + + obj a_moc : dir1/qt_file.h : <library>/qt//qt ; + exe a : a.cpp a_moc ; + obj b_moc : dir2/qt_file.h : <library>/qt//qt ; + exe b : a.cpp b_moc ; + + Explicitly changing name for the problematic files. + + 3. Generally change V2 so that directory part of source is preserved. This + will generate targets: + "bin/msvc/debug/dir1/moc_qt_file.cpp" and + "bin/msvc/debug/dir2/moc_qt_file.cpp". No problems. + + However, there are some additional questions: + + - What if source has absolute file name? + - What if source is "../../include/qt_file.h"? + + We can ignore directory names in those cases (i.e. use the current + behaviour) but that would be a bit inconsistent. + +Any opinions? + +Pedro Ferreira: + +I think this is a corner case and BB should not try to solve everything +automatically - otherwise it will become really complex. +I don't see a problem in requiring the user to help the build system by +using solutions 1 or 2. +Of course, the better the error reporting, the easier it will be to +find the cause and the cure of the problem. + +TEMPLIE Cedric: + +I agree with Pedro. Solution 1 or 2 is the best way to deal with this +problem. Of course I have a preference for the solution 1, but the +solution 2 has the advantage to work without any modification... + +Toon Knapen: + +I agree. + + diff --git a/src/boost/tools/build/notes/release_procedure.txt b/src/boost/tools/build/notes/release_procedure.txt new file mode 100644 index 00000000..f17f38a2 --- /dev/null +++ b/src/boost/tools/build/notes/release_procedure.txt @@ -0,0 +1,83 @@ +Copyright 2003, 2005, 2006 Vladimir Prus +Distributed under the Boost Software License, Version 1.0. +(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt) + + + Boost.Build V2 release procedure. + +[ Must be done from a Unix shell ] + +0. Look for all issues for current milestone in the tracker. Close the fixed one, + if not already closed. Move to a later milestone, or fix all the unfixed + ones. + + Make sure that "bjam --version" output is correct. Update version string if + needed. Update bjam version and the version check is necessary. + Check the download locations in "index.html". Check that "last modified" + string in index.html is correct. + +1. Make sure you don't have any local modification, and create SVN directory + + https://svn.boost.org/svn/boost/branches/build/Milestone_X + + Then, copy: + + https://svn.boost.org/svn/boost/trunk/tools/build + https://svn.boost.org/svn/boost/trunk/tools/jam + + to that directory. + +2. Run + + svn co https://svn.boost.org/svn/boost/branches/build/Milestone_X boost-build + +3. Go to "boost-build/build/v2" directory. + +4. Run "./roll.sh". This will create "boost-build.zip" and + "boost-build.tar.bz2" in parent directory, and also upload + new docs to sourceforge. + +5. Unpack "boost-build.tar.bz2", and build jam. + +6. Go to "test" and copy "test-config-example.jam" to "test-config.jam". + If you're not ghost, edit test-config.jam to specify all the right paths. + Run gcc tests: + + python test_all.py gcc --extras + +7. Build all projects in examples-v2, using the bjam binary created at step 4. + Note: "threading=multi" might be needed to build QT examples. + +8. Make SF release: + + - Go to + https://sourceforge.net/project/admin/editpackages.php?group_id=7586 + + - Create new Boost.Build release. Name it 2.0-mXX + + - Upload the changelog. Be sure to turn the "Preserve my pre-formatted + text" checkbox. + + - Rename previously built packages to boost-build-2.0-mXX.tar.bz2 + and boost-build-2.0-mXX.zip. Upload them to the + /incoming directory on ftp://upload.sourceforge.net + + - Add those file to release, edit file properties. + + - In a separate browser, verify changelog is not damaged. + + - In a separate browser, Download the files and verify checksums. + + - In SF file release interface, send email notice. + +9. Announce the release, etc. + +10. Login to SF and update the current-release redirects in + /home/groups/b/bo/boost/htdocs/boost-build2/.htaccess. + +11. If any issues were found during release in this document or in + test-config-example.jam, commit those changes. The release need + not be redone, but changes must be committed. + +12. Set release date in changes.txt and commit. + |