The targets (both abstract and virtual) used to refer to project there belong
to using the name of Jamfile module corresponding to the project. That was a
bit messy, and whatevet it was necessary to get any project attribute, one
had to call 'project.attribute', which was messy too.
Now, projects are identified by instance of project-target class, and
attributes are obtained via 'get' method in that class.
[SVN r23001]
The targets (both abstract and virtual) used to refer to project there belong
to using the name of Jamfile module corresponding to the project. That was a
bit messy, and whatevet it was necessary to get any project attribute, one
had to call 'project.attribute', which was messy too.
Now, projects are identified by instance of project-target class, and
attributes are obtained via 'get' method in that class.
[SVN r23001]
1. Don't break where there are several elements in condition.
2. Don't validate <toolset> feature in condition, since we might
not have initialized all possible toolsets.
[SVN r22964]
1. Don't break where there are several elements in condition.
2. Don't validate <toolset> feature in condition, since we might
not have initialized all possible toolsets.
[SVN r22964]
'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]
'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]
we added only dll-path properties and the logic that created dll-path
properties from xdll-path properties did not work right on Windows.
It makes more sense anyway to always add all paths for dendency libraries.
[SVN r22932]
we added only dll-path properties and the logic that created dll-path
properties from xdll-path properties did not work right on Windows.
It makes more sense anyway to always add all paths for dendency libraries.
[SVN r22932]
not only on the one we're staging.
On Windows, the action that produces EXE also produces RSP file. If location
of RSP file is not changed when staging, both staged EXE and original EXE will
try to use the same RSP file and that will cause 'duplicate virtual target'
error.
[SVN r22931]
not only on the one we're staging.
On Windows, the action that produces EXE also produces RSP file. If location
of RSP file is not changed when staging, both staged EXE and original EXE will
try to use the same RSP file and that will cause 'duplicate virtual target'
error.
[SVN r22931]
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]
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]
