metacharacters, Boost.Build misbehaved.
* new/path.jam
(all-parents): Don't use regex to strip path prefix, use a more robust
approach.
* test/bad_dirname.py: New test.
[SVN r18576]
metacharacters, Boost.Build misbehaved.
* new/path.jam
(all-parents): Don't use regex to strip path prefix, use a more robust
approach.
* test/bad_dirname.py: New test.
[SVN r18576]
build-system.jam - moved from tools/build/new to tools/build
boost-build.jam - moved from tools/build/new to tools/build/kernel
bootstrap.jam
errors.jam
modules.jam
test/BoostBuild.py - adjusted for the above modification
test/boost-build.jam
project-root.jam - renamed to "project-roots.jam" to avoid confusion
and conflict with the user's project-root.jam file
project.jam - adjusted for the above renaming
test/project-test1/project-test1.jam
type.jam - broke a circular module dependency
[SVN r18575]
build-system.jam - moved from tools/build/new to tools/build
boost-build.jam - moved from tools/build/new to tools/build/kernel
bootstrap.jam
errors.jam
modules.jam
test/BoostBuild.py - adjusted for the above modification
test/boost-build.jam
project-root.jam - renamed to "project-roots.jam" to avoid confusion
and conflict with the user's project-root.jam file
project.jam - adjusted for the above renaming
test/project-test1/project-test1.jam
type.jam - broke a circular module dependency
[SVN r18575]
role as well, so that small projects can use only one file.
* new/project.jam
(load): Load project root at the very start, in case it wants to
be Jamfile.
(act-as-jamfile): New rule.
(module-name): Allow to tweak the name of module associated with a location.
[SVN r18557]
role as well, so that small projects can use only one file.
* new/project.jam
(load): Load project root at the very start, in case it wants to
be Jamfile.
(act-as-jamfile): New rule.
(module-name): Allow to tweak the name of module associated with a location.
[SVN r18557]
* new/project.jam
(load): Prevent loading jamfile twice here, since we have all the
necessary data.
(load-jamfile): Don't try to check for duplicate loading (the check
was a bit clumsy, anywhay). Remove 'loaded-var' parameter.
[SVN r18556]
* new/project.jam
(load): Prevent loading jamfile twice here, since we have all the
necessary data.
(load-jamfile): Don't try to check for duplicate loading (the check
was a bit clumsy, anywhay). Remove 'loaded-var' parameter.
[SVN r18556]
* new/project.jam
(inherit-attribute): New rule, extracted from 'initialize'.
(initialize): Allow 'jamfile' parameter to be empty, in which case
the project is 'standalone'.
[SVN r18544]
* new/project.jam
(inherit-attribute): New rule, extracted from 'initialize'.
(initialize): Allow 'jamfile' parameter to be empty, in which case
the project is 'standalone'.
[SVN r18544]
they are located. The problem with using the directory name is that we might
want toolset modules to act as project, and directory name is not unique then.
We might even want to declare two projects in the same module.
[SVN r18542]
they are located. The problem with using the directory name is that we might
want toolset modules to act as project, and directory name is not unique then.
We might even want to declare two projects in the same module.
[SVN r18542]
- darwin-tools.jam; added warnings feature to control warning output.
- darwin-tools.jam; disable some Apple speicfic options when using g++ directly.
- darwin-tools.jam; disable dylib versioning, for now.
- python.jam; remove shared link to pyton2.3 lib for embebed targets.
- python.jam; remove uneeded path to python libraries, implicitly there because of framework use.
- python.jam; disable warnings, for now.
[SVN r18529]
- darwin-tools.jam; added GCC* env setup variables to allow for using something other than the built in gcc.
- darwin-tools.jam; tweaked the bundle-loader feature to also add the bundle as a link object.
- python.jam; wire in the framework path for python.
- python.jam; remove the <framework> feature from built PYDs.
[SVN r18522]
* new/stage.jam
(stage-target-class.construct): Pass the result via
'virtual-target.register'. I wonder if virtual targets should
be create via 'virtual-target.create' which will invoke
'virtual-target.register' internally. Passing via 'register' was forgotten
in many places.
* test/stage.py: New test.
[SVN r18497]
* new/stage.jam
(stage-target-class.construct): Pass the result via
'virtual-target.register'. I wonder if virtual targets should
be create via 'virtual-target.create' which will invoke
'virtual-target.register' internally. Passing via 'register' was forgotten
in many places.
* test/stage.py: New test.
[SVN r18497]
