and if program does exit(1) we get '1'. The code for checking was
using os.WIFSIGNALLED, and that returns true for '1' -- it seems like
it is expecting result of os.system, which would be 256, or something.
[SVN r62634]
It contains so many formatting changes to as make porting things to
Python impossible. I'll cherry-pick the todo and non-formatting changes
soonish.
[SVN r56034]
Problem detected & and a reproducible example constructed by Juraj Ivančić. Debugged by Vladimir Prus. Patched and packaged by Jurko Gospodnetić.
[SVN r48590]
with <include>a&&b
* tools/buitin.jam
(c-scanner.__init__) split includes at &&
* test/test_all.py test/ordered_include.py
Test case for this fix.
[SVN r47537]
not cause errors in subprojects.
* build/property.jam
(tranlate-dependencies) New rule to bind dependency
properties to the project that they are specified in.
* build/property-set.jam
(create-from-user-input) Add call to property.translate-dependencies
* test/test_all.py test/inherited_dependency.py
Test case for this fix.
[SVN r47536]
When scanning directories and creating a list of all their content (filent.c) it would identify all the located files and folders using their long file names. On the other hand, referencing a target using its short file name inside a Jam script caused Boost Jam to reference those files twice using two separate TARGET structures - one identified using the file's short name and one using the file's long name.
One bad example was the MkDir which would always attempt to create a folder identified by its short name even if that folder already existed (due to the NOUPDATE rule getting applied on the incorrect TARGET).
The change does not affect targets whose names do not represent existing file names.
Also, it seems to me that the short_path_to_long_path() call in file_dirscan() in the filent.c module should most likely be moved to file_info() in the filesys.c module. This would make mapping file names to file_info_t & TARGET structures consistent. However, I have not done this in this patch just to make the patch as minimal as possible.
Prepared tests have been do nothing on non Windows platforms.
[SVN r45144]
seems that doxygen target now produces a target
with different name, and it does not produce
any target unless there's explicit dependency
on it. I'm not sure I like the change, but
anyway.
[SVN r39605]
* BoostBuild.py; Make the matching of content and files be more loose and use pattern globbing of toolset names.
* glob.py/project_glob.py; Rename to avoid collision with builtin Python module.
* all; Update copyrights and license info.
[SVN r35729]
alias foo : [ run a.cpp ] ;
and
exe main : main.cpp [ lib helpers : helpers.cpp ] ;
Now inline targets are marked explicit, so that they are not
build unless requested, and for the alias target, the names
of inline targets are not qualified by the name of top-level target.
build/
* alias.jam (alias): Pass 'no-renaming' to
target.main-target-sources.
* target.jam (main-target-sources): New parameter
'no-renaming'. Make inline target explicit.
* builtin.jam (lib): Declare 'result' variable,
to avoid implicit declaration of a global one.
tools/
* testing.jam (test-suite): Make synonymous with 'alias'.
test/
* inline.py: Adjust to the fact that alias no longer
changes names of inline targets. Check that inline
targets are explicit.
[SVN r35607]
bjam --clean some_main_target
don't clean files belonging to other main targets, even if those other main
targets are dependencies of 'some_main_target'.
[SVN r32760]
to 'make', sine it's no longer supported.
Allow to call 'flags' on local rule. Use flag settings on local rule to
implement the effect previously achieved with extra arguments.
[SVN r32723]
affect the names of the generated targets and only usefull for preventing
V2 from treating two independent targets as target alternatives.
[SVN r32720]
The issue is that when with new response files the names of libraries we're
trying to link to is not emitted with "bjam -n", so remove "-n" and explicitly
look in response files.
[SVN r32341]
There were two problems:
- 'glob' was using __name__ as the name of the project and not
project.current, so it would search in project root, and not in child
project that inherited project root rules.
- the 'import' that's overrided in project context used __name__ to
restore the value of current project
Thanks to Emil Dotchevski for the bug report.
[SVN r30507]
* If a generator was given a source it could not handle, it used to return
that source together with generated targets. This was nice for some use
cases, but no very nice for others, and this behaviour could not be turned
off. One use case where it worked bad was:
lib plugin : plugin.cpp helper ;
lib helper : helper.cpp ;
On windows, 'plugin' would link to the 'import library' and pass the DLL
target though. So, when installing 'plugin', we'd also install 'helper.dll',
and it was not possible to do anything about it.
* If we asked generators.construct to produce sources of type CPP,
and the selected generator produced both targets of type CPP, and of
some other type, we'd try again to convert those other targets to CPP.
This simply complicated the logic for no good reason.
* Most generator function had 'multiple' parameter, which function
was long forgotten by anybody.
As a bit of history, I believe some of the above decisions were due to a
certain use case:
CPP <------- WHL
\
WD
/
CPP <------- DLP
Here, a source file is converted to two targets with one command, and each
produced file is converted to CPP. Our generators search would notice that
there are two generators for CPP: the WHL->CPP and DPL->CPP
generators. Neither is better that the other so both are tried, and produce
(CPP, DPL) and (CPP, WHL) pairs of targets. To avoid reporting an ambiguity,
we'd try to convert, DLP to CPP and WHL to CPP, do it successfully, notice
that produced targets are the same and decide that there's no ambiguity.
However, this is rather complex logic for a relatively rare case. It can
be handled by writing another WD->CPP generator that would handle
disambiguation itself.
This commit has one user-visible change. The code:
exe a : a.cpp b ;
obj b : b.cpp helper;
lib helper ;
No longer works -- the 'a' target won't link to 'helper'. However, this is
pretty stange code and worked before almost by accident.
[SVN r29361]
The problem with the previous implementation is that it would iterate
over all elements in a dir even if 'pattern' had no metacharacters. First,
that was slow -- if you handed
/cygdrive/w/My Documents/boost/test/a.cpp
to it, it would crawl all the way to the top, listing each directory and
checking each file. Second, it would fail, because Cygwin is broken and
does not show 'cygdrive' is the list of directory elements of '/'.
Now we check if a pattern has metacharacters, and if not, just do
a simple 'timestamp' call.
The new glob is implemented as new 'GLOB-RECURSIVELY' builtin. I've decided
to use builtin since otherwise, we'd need 'does this name exist' builtin,
and if we need new builtin, why don't implement all globbing in core.
[SVN r29163]
The <tag> rule if often used in Jamfile like this: <tag>@$(__name__).rule.
The __name__ looks like Jamfile<jamfiles'directory>. When directory has
a dot, we we confused and took the part till the first dot as the
name of module.
Now, such values are processed closer to the definition point, where
we know the name of the module and don't need to guess it by looking at
the name.
Thanks to Juergen Hunold for the bug report.
[SVN r28063]
* build/generators.jam
(generator.generated-targets): Comment the desired semantics.
* util/utility.jam
(basename): Take the part till the last dot, not the first.
[SVN r27374]
tools/testing.jam
Support rules for measuring timing of build steps.
build/generators.jam
Generators with empty source lists can now consume any target type.
[SVN r27335]
builtins.{c,h}
Support for the REBUILDS rule
remove unused variable
rules.h
make.c
Support for the REBUILDS rule
make1.c
Support for the REBUILDS rule
Support for recording timing information
Restructured a case statement because it was masking a bug I
introduced.
execcmd.h
execnt.c
execunix.c
Support for recording timing information
Also removed NT-specific stuff from execunix
expand.c
Removed tabs from critical comment
Added tab-width variable setting comment for emacs.
v2/test
rebuilds.py, timedata.py, test_all.py
Tests for REBUILDS and timing.
[SVN r27334]
to direct dependents. The previous behaviour can be confusing and
there are no use cases where the new behaviour will be bad.
It will add more include paths in some cases, but who cares?
[SVN r26528]
Thanks to Toon Knapen for the bug report.
* tools/builtin.jam
(archiving-generator.run): Add <library> properties to sources.
* test/library_chain.py: New test.
[SVN r26447]
* tools/stage.jam
(copy-file, relink-file): Add stage's dependency properies to
the staged targets properties, so that <dependency> is copied too.
* test/stage.py: New test.
[SVN r26420]
enviroment variables in the list of values. No it's possible to add
an element to a variable.
* build/project.jam: Remove obsolete test.
* build/toolset.jam (find-property-subset): No longer local,
so that test can call it.
* test/test.jam: Import 'print' and 'common'.
* util/print.jam: Comment out failing unit test.
[SVN r26413]
* build/targets.jam
(project-target.find): Better error reporting.
* build/project.jam
(load-jamfile): Use 'path.native' when loading Jamfile,
otherwise, target id with absolute directory name won't
work for Windows.
[SVN r26271]
(load-parent): New rule, extracted from 'initilize'.
(load-jamfile): If loading project-root.jam, check for
Jamfile and load it in the same module.
(inherit-attributes): Simplify.
(project-rules.constant, project-rules.path-constant): New rules.
* build/targets.jam
(project-target.__init__): New paramater 'parent'.
(project-target.inherit)
(project-target.add-constant)
(project-target.intern-constants): New rules
*
[SVN r26251]
* build/project.jam
(project-context.use-project): Just record parameters, don't do anything.
(load): After Jamfile is loaded, use data recorded above to load
additional projects.
* test/test_all.py: New test.
[SVN r26229]
as the first elements of result. Those usage requirements will be combined
with explicitly specified for the main target.
This is yet another step towards making 'main target classes' unnecessary.
* build/generators.jam
(try-one-generator): Check if generator returned usage requirements or not.
(construct): Make sure first element of result is always property set.
(many other methods): Induced changes
* tools/builtin.jam
(exe-target-class, lib-target-class): Remove.
(linking-generator, seached-lib-generator): Compute usage requirements.
(archiving-generator): New class
[SVN r26192]
property, since it's typically used when only headers are used.
* build/virtual-target.jam (subvariant.all-referenced-targets): Return
the names of properties.
* tools/stage.jam (stage-target-class.collect-targets): Filter out <use>
Thanks to Jurgen Hunold for the bug report.
[SVN r26052]
* v2/tools/gcc.jam
(init): parse the new options and call the new rule.
(init-link-flags): new rule. Initialize flags based on linker type.
put back -minpure-text
* v2/test/conditionals.py
small modification to avoid empty binaries.
Patch from Andre Hentz.
[SVN r25764]
would force us to relink all libraries when staging.
Now that libraries do not hardcode dll paths, add a check that correct
-rpath-link options are added. When staging, we don't hardcode-dll-paths,
and libraries never hardcode dll paths, so if there's a long chain of
libraries, we should add -rpath-link, otherwise the linker won't find
the dynamic libraries and will complain.
[SVN r25756]
lib png : z : <name>png ;
lib z : : <name>z ;
now works: if you link to 'png' you'll also link to 'z'.
lib png : z : <file>png.a ;
lib z : : <file>z.a ;
now works too. The 'prebuilt.jam' modules which used to handle <file> for
all target kinds is now removed.
[SVN r25703]
* build/toolset.jam (inherit-generator): New parameter 'generators-to-ignore'.
* tools/gcc.jam: Ignore *link* generators when inheriting. Declare the
gcc specific generator.
* test/gcc_runtime.py: Test that <link-runtime>static is correctly handled.
The gcc specific generator is necessary exactly for that reason.
[SVN r25700]
'rank' for each viable generator, we use explicit information of the
form 'generator A is better than generator B', which is provided by
the user. The obvious goal is to fix 'custom_generator' failure on
msvc, but generally, I'm fixing BB76 -- which says that current generators
selection is very broken.
[SVN r25361]
msvc, 0 is returned and that broke the test. But really, we're interested
only if user-defined generator is run, not that the result is compiled.
[SVN r24779]
(from-file): Use full file name as search key, to avoid creating two
different targets from two different project, which actually correspond
to the same file.
(register): Use actual name of the target as key. This again avoid
the problem with two equivalent targets in two different projects.
[SVN r23173]
'toolset' and 'threading'. The reason is that current link-compatibility
check is way too simple minded and produces bogus warnings. For example,
linking MT library into single threaded application is OK. Likewise, some
toolsets are link-compatible.
We might need a better mechanism, but for now just make the feature
link-compatible. Useless warnings are much worse than failure to report
link-incompatibility in some cases.
[SVN r22949]
a couple of cases.
1. On Windows, DLLs are never directly linked to, so they are considered
unused and cause a warning. There used to be special code in
exe-target-class and lib-target-class to supress that warning, but this
failed for unit-test, for example, since main target class for unit test
is not related with exe-target-class. And making yet another main target
class looks ugly.
2. A target specified via project-wide <source> or <library> property is
added to sources for all targets, and cause a warning when it's not used.
However, there are valid cases to ignore such sources. For example
obj a : a.cpp : <optimization>off ;
need to comsume any libraries.
It was not clear how to fix both problems. Further, the only case when I found
the warning to be usefull is when declaring new toolsets, and it that case it
does not add much information compared to --debug-generators output. So, let's
just kill the feature for now.
[SVN r22927]
The used 'CALLER_MODULE' to determine the project where the main target
is to be declared, which did not work if the rule is called from another
module.
Thanks to Zbynek Winkler for the bug report.
* build/project.jam (current): New rule
* test/wrapper.py: New test
* other files: Use 'project.current'.
[SVN r22569]
Patch from Andre Hentz.
* v2/build/toolset.jam
(inherit-flags): Take an extra parameter describing properties that
should not be inherited.
* v2/build/type.jam
(register-suffixes): Removed local qualifier.
* v2/test/BoostBuild.py
(prepare_suffix_map): Add .dylib if OS is Darwin.
(Tester::_init_): path to bjam on Darwin.
* v2/test/prebuilt.py
make sure $toolset is expanded correctly.
* v2/test/prebuilt/project-root.jam
use $toolset instead of gcc.
* v2/test/prebuilt/ext/project-root.jam
use $toolset instead of gcc.
* v2/test/prebuilt/ext/Jamfile2.jam
handle extension .dylib.
* v2/test/prebuilt/ext/Jamfile2.jam
handle extension .dylib.
* v2/tools/darwin.jam
inline call to toolset.inherit.
filter <debug-symbols>off because -s is not accepted for dlls.
speficy that .dylib files are of type SHARED_LIB.
(actions link): pass -s for static linkage.
(actions link.dll): pass -L flag with path to libraries.
(actions archive): -c inhibits warning.
[SVN r22332]
* test/BoostBuild.py:
(Tester): added a check for SunOS and one for Linux. The default now is
to raise an exception.
Patch from Andre Hentz.
[SVN r21663]
options to the linker.
* tools/builtin.jam
(lib-target-class.compute-usage-requirements): Add xdll-path
properties instead of dll-path. Add them unconditionally,
not only when hardcode-dll-paths is true.
(linking-generator.run): When hardcode-dll-paths is true, add
dll-path property for each xdll-path property.
* tools/gcc.jam
Convert xdll-path properties into -rpath-link option.
[SVN r21560]
* tools/builtin.jam
(linking-generator): Move <library> properties to sources in the 'run'
method. This makes the logic usable by everyone who invokes the generator.
(exe-target-class, lib-target-class): Don't do the above.
[SVN r20707]
we need to bypass <library-path> property, as well.
* tools/builtin.jam
(lib-target-class.compute-usage-requirements): The above change.
* build/virtual-target.jam
(subvariant.set-usage-requirements, subvariant.usege-requirements):
New methods.
(abstract-file-target.dg): Don't allow changing the value.
* build/targets.jam
(basic-target.generate): Explicitly don't change value of 'dg'.
[SVN r20655]
* build/targets.jam
(basic-target.refined-properties): expand composites in the 'requirements' property-set.
Patch from Paul Lin.
* tests/composite.py: New test.
[SVN r20615]
* new/builtin.jam
(link-action.adjust-properties): Remove.
(linking-generator.generated-targets): Do what adjust-properties used to do.
(linking-generator.run): Convert <library> properties to sources.
(exe-generator): New class.
[SVN r20455]
to Austin Bingham for the bug report.
* new/project.jam
(load): Don't mark project as loaded here.
(load-jamfile): Mark it as loaded here.
[SVN r20439]
* new/targets.jam
(main-target.select-alternative): Rewrite.
(main-target.generate-really): Issue error in all cases where best
alternative could not be found.
(basic-target.match): Renamed from 'match-rank' and changed.
* boost_build_v2.html: Document new algorithm.
* test/alternatives.py: More tests.
[SVN r20331]
projects, and for individual targets, it will reappear later.
* new/property.jam:
(refine): Don't check for link-compatibility.
* new/targets.jam
(project-target.generate): Don't call 'refine' and don't emit any
warnings.
(basic-target.match-rank): The alternative selection mechanism dependended
on link-compatibility in some way. Work around the difference in semantic
we have now. This will be resolved in a more clean way later.
* new/property-set.jam
(property-set.link-incompatible, property-set.link-incompatible-with):
New methods.
[SVN r20190]
* new/virtual-target.jam
(subvariant-dg.implicit-includes): New method.
(subvariant-dg.__init__): Check for <implcit-dependency>, not all
dependency features.
* new/builtin.jam
(compile-action.adjust-properties): Call 'implicit-includes'.
[SVN r20174]
* new/generators.jam
(generator.__init__): Use parallel lists to store prefixes and postfixes
for a name, not mapping with type as a key, since type is not unique.
(generator.generated-targets): Adjust.
[SVN r19990]
Thanks to Peter Schoen for bugreport.
* new/project.jam (initialize): Set 'project-root-module' attribute.
* new/project_root.py: New test.
[SVN r19899]
* jam_src/builtins.c: New builtins IMPORT_MODULE and IMPORTED_MODULES.
jam_src/rules.c: (bindrule): Refactor. (lookup_rule): New function.
* kernel/modules.jam: Make use of IMPORT_MODULE.
[SVN r19422]
rather then only defined on first.
The previous behaviour did not work when there were "default-build" attribute
on project and two alternatives for a main target.
Patch from Michael Stevens.
[SVN r19303]
* new/targets.jam
(project-target.add-alternative): New rule.
(project-target.build-main-targets): New rule.
(project-target.generate, project-target.main-target,
project-target.has-main-target): Call 'build-main-targets'
(project-target.rename-main-target): Remove.
(main-target-sources): Use 'rename', not project.rename-main-target.
(main-target-alternative): Simplify.
* test/inline.py: Test for fix.
[SVN r19245]
* new/builtin.jam
(lib-generator): Remove.
(lib-target-class): New class. Target class is more powerfull then
generator, here.
* new/generators.jam
(construct): New argument 'return-all'.
* bew/property-set.jam
(property-set.add-raw): New method.
[SVN r18917]
not by project attribute. The problem with the previous interface was
that it was not possible to mark target as explicit anywhere else,
such as in helper module which declares target in project module, or
in toolset module.
* new/targets.jam
(project-target.mark-target-as-explicit): New rule
(project-target.targets-to-build): Use self.explicit-targets.
* new/project.jam
(project-attributes.set): Don't allow 'explicit-targets'.
[SVN r18900]
it included MSVC...
* new/toolset.jam:
Allow action names with dots, so that we can set flags for
gcc.compile.c, gcc.compile and gcc and combine those flags.
* tools/gcc.jam: Use 'gcc' for compiling C files. There's still a problem:
'init' rules does not allow to configure name of C compiler. Also, don't
declare flags individually for gcc.link and gcc.link-dll.
* tools/borland.jam: Force C++ compile when needed.
[SVN r18774]
* new/project-root.jam (project-root-context.project): New rule
(find-project-rule): New rule, factored out of 'load' so that it can
be used elsewhere.
* new/project.jam (find): When project is not yet known, try loading
project-root, not only Jamfile.
[SVN r18759]
are communiated via return value of 'abstract-target.generate', not as
attribute of virtual target. The advantage is that we can return usage
requirements, even if no targets were created.
Also, usage requirements is not really attribute of virtual target. If several
virtual targets are created for one main target, the previous code would set
the same usage requirements on all virtual targets.
[SVN r18689]
* new/project.jam
(lookup) Don't support project location in front of "@".
(lookup-with-load): Remove.
(find): New rule.
(find-target): move to...
* new/target.jam
(find): Here. And simplify.
[SVN r18667]
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]
* 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]
