link=shared and runtime-link=static
In present, with --build-type=complete all variants with <link>shared and <runtime-link>static are explicitly not built, because they are deemed risky. The code to exclude those variants is written in such a way that: 1. It produces pile of unclear messages. 2. It prevent build of those variants no matter what -- even if you specify this explicitly on command line, you'll get nothing built. I am fixing (1) and this allows (2) to be changed. Should I? In other words, what should happen if user say: bjam link=shared runtime-link=static ? Options are: 1. This variant is built. 2. This variant is built, a huge warning is printed. 3. Error is emitted, user can pass --yes-I-know-what-I'm-doing to build 4. Error is emitted. I believe that on Linux, (4) is most appropriate. I don't know about Windows. Comments? - Volodya
? Options are:
1. This variant is built. 2. This variant is built, a huge warning is printed. 3. Error is emitted, user can pass --yes-I-know-what-I'm-doing to build 4. Error is emitted.
I believe that on Linux, (4) is most appropriate. I don't know about Windows. Comments?
Definitely (4) for MSVC IMO. John.
John Maddock wrote:
? Options are:
1. This variant is built. 2. This variant is built, a huge warning is printed. 3. Error is emitted, user can pass --yes-I-know-what-I'm-doing to build 4. Error is emitted.
I believe that on Linux, (4) is most appropriate. I don't know about Windows. Comments?
Definitely (4) for MSVC IMO.
Ok. Given that such property combination resulted in target been skipped for quite some time, and no complains arises, I've now added an explicit error message. - Volodya
Vladimir Prus wrote:
? Options are:
1. This variant is built. 2. This variant is built, a huge warning is printed. 3. Error is emitted, user can pass --yes-I-know-what-I'm-doing to build 4. Error is emitted.
Ok. Given that such property combination resulted in target been skipped for quite some time, and no complains arises, I've now added an explicit error message.
This change seems to have broken our VeecoFTC regression tests on the trunk (MSVC 9 with STLport 5.2). I am now getting the following message on every test cycle: error: link=static together with runtime=link is not allowed error: such property combination is either impossible error: or too dangerous to be of any use As far as I am aware, I am not explicitly requesting any link/runtime-link configuration on the command line so it appears that the default configurations are having issues. Our command line and user-config.jam info is available at: http://www.boost.org/development/tests/trunk/VeecoFTC.html Please let me know if there is something that appears to be mis-configured or that I need to change. Thanks, -Dave
David Deakins wrote:
Vladimir Prus wrote:
? Options are:
1. This variant is built. 2. This variant is built, a huge warning is printed. 3. Error is emitted, user can pass --yes-I-know-what-I'm-doing to build 4. Error is emitted.
Ok. Given that such property combination resulted in target been skipped for quite some time, and no complains arises, I've now added an explicit error message.
This change seems to have broken our VeecoFTC regression tests on the trunk (MSVC 9 with STLport 5.2). I am now getting the following message on every test cycle:
error: link=static together with runtime=link is not allowed error: such property combination is either impossible error: or too dangerous to be of any use
As far as I am aware, I am not explicitly requesting any link/runtime-link configuration on the command line so it appears that the default configurations are having issues. Our command line and user-config.jam info is available at:
http://www.boost.org/development/tests/trunk/VeecoFTC.html
Please let me know if there is something that appears to be mis-configured or that I need to change.
This is interesting, and in fact -- it's nice that this change caught his behaviour. Can you go to the 'status' directory, run: bjam --debug-building msvc/toolset-msvc:version=9.0~wm5~stlport5.2/stdlib=stlport-5.2~evc9~arm and, if that reproduces the problem, send me the complete output by direct mail? Thanks, Volodya
David Deakins wrote:
Vladimir Prus wrote:
? Options are:
1. This variant is built. 2. This variant is built, a huge warning is printed. 3. Error is emitted, user can pass --yes-I-know-what-I'm-doing to build 4. Error is emitted.
Ok. Given that such property combination resulted in target been skipped for quite some time, and no complains arises, I've now added an explicit error message.
This change seems to have broken our VeecoFTC regression tests on the trunk (MSVC 9 with STLport 5.2). I am now getting the following message on every test cycle:
error: link=static together with runtime=link is not allowed error: such property combination is either impossible error: or too dangerous to be of any use
Thanks for providing me, offlist, with the necessary logs. This happens to be preexisting problem -- if you look at iostream testresults from you, you will find none. The reason is that iostream's Jamfile had this: 29195 turkanis <toolset>msvc,<stdlib>stlport:<link-runtime>static This requirement was there since the beginning. I've removed it -- we'll see how the test result will look. There's a chance that some other libraries does the same, if so, I'll need debug output again. Thanks, Volodya
Vladimir Prus wrote:
David Deakins wrote:
This change seems to have broken our VeecoFTC regression tests on the trunk (MSVC 9 with STLport 5.2). I am now getting the following message on every test cycle:
error: link=static together with runtime=link is not allowed error: such property combination is either impossible error: or too dangerous to be of any use
Thanks for providing me, offlist, with the necessary logs. This happens to be preexisting problem -- if you look at iostream testresults from you, you will find none. The reason is that iostream's Jamfile had this:
29195 turkanis <toolset>msvc,<stdlib>stlport:<link-runtime>static
This requirement was there since the beginning. I've removed it -- we'll see how the test result will look.
There's a chance that some other libraries does the same, if so, I'll need debug output again.
Thanks for the quick response! I'll start a new testing cycle and we'll see where we get to. -Dave
participants (3)
-
David Deakins -
John Maddock -
Vladimir Prus