Conflicts when building libraries at root

Peter Dimov

4 Jan 2015 4 Jan '15

3:06 p.m.

On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get error: Name clash for 'libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on When I add --without-context --without-coroutine, I now get error: Name clash for 'libboost_system-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>off error: - <asynch-exceptions>on So I add --without-test. error: Name clash for 'libboost_timer-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>on <library>object(file-target)@10959 error: - <asynch-exceptions>off <library>object(file-target)@9953 Now where did _that_ come from. :-) Ah. --without-endian. Builds now. This is perhaps old news for some, but it looks like it doesn't play well with our simple build instructions. Or maybe it doesn't occur on the master branch, so we don't care? I haven't checked yet. It's also perhaps an indication of a deeper problem. I can use b2 --with-test and have 'test' built; it builds its dependencies (system, chrono and timer) with <asynch-exceptions>on in bin.v2, and if I use it from within Boost.Build, it will link to them. But if I stage (or install) Boost.Test, and then stage or install Boost.System separately, Boost.System will be built with <asynch-exceptions>off. So the library user who just has headers and binaries will link those, potentially creating a conflict, which may in this case be benign. Or not.

Show replies by date

Jürgen Hunold

4 Jan 4 Jan

3:48 p.m.

Hi Peter, Am Sonntag, 4. Januar 2015, 17:06:42 schrieb Peter Dimov:

...

On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get

error: Name clash for 'libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on

When I add --without-context --without-coroutine, I now get

Known issue, see http://lists.boost.org/boost-build/2014/12/27774.php et. al.

...

Ah. --without-endian. Builds now.

Yes, I've pushed a PR for Boost.Endian in Oktober: https://github.com/boostorg/endian/pull/7 CC'ing the maintenance team now. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Vladimir Prus

5 Jan 5 Jan

8:40 a.m.

On 01/04/2015 06:48 PM, Jürgen Hunold wrote:

...

Hi Peter,

Am Sonntag, 4. Januar 2015, 17:06:42 schrieb Peter Dimov:

...
On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get

error: Name clash for 'libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on

When I add --without-context --without-coroutine, I now get

Known issue, see

http://lists.boost.org/boost-build/2014/12/27774.php et. al.

...
Ah. --without-endian. Builds now.

Yes, I've pushed a PR for Boost.Endian in Oktober:

https://github.com/boostorg/endian/pull/7

CC'ing the maintenance team now.

Huh, that's embarassing :-( I'm not entirely sure how build changes are supposed to work in git world, am I at liberty to commit build-related patches to any library, provided the maintainer does not respond in reasonable time? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Jürgen Hunold

7:37 p.m.

Hi Volodya, Am Montag, 5. Januar 2015, 11:40:03 schrieb Vladimir Prus:

...

On 01/04/2015 06:48 PM, Jürgen Hunold wrote:

...
Yes, I've pushed a PR for Boost.Endian in Oktober:

https://github.com/boostorg/endian/pull/7

CC'ing the maintenance team now.

Huh, that's embarassing :-(

Just got fixed by renaming the directory to "benchmarks".

...

I'm not entirely sure how build changes are supposed to work in git world, am I at liberty to commit build-related patches to any library, provided the maintainer does not respond in reasonable time?

One of the problems not really solved. I should have posted to the maintenance list earlier. And sometimes the fixes are not so easy or you chose the wrong solution. Unfortunately, we still have Boost.Context open. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Vladimir Prus

18 Feb 18 Feb

11:28 a.m.

New subject: [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)

On 01/05/2015 10:37 PM, Jürgen Hunold wrote:

...

...
I'm not entirely sure how build changes are supposed to work in git world, am I at liberty to commit build-related patches to any library, provided the maintainer does not respond in reasonable time?

One of the problems not really solved. I should have posted to the maintenance list earlier. And sometimes the fixes are not so easy or you chose the wrong solution.

Unfortunately, we still have Boost.Context open.

Okay, so the problem we're facing is that building master results in: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <address-model>32 <architecture>x86 What happens is this: - Context library is built - It detects default address model and architecture of the current toolchain, and adds those to requirements - Since there's a global dependency on 'headers' target, this pretty much immediately rebuilds everything with new address-model and architecture properties. - We get property set clash One way to solve this is to restructure Boost.Context setup so that added properties do not escape. It's doable, but probably will be fragile. Another way is to take libs/context/config, move it to libs/config, and make sure these properties are applied globally. That seems preferable. John, any objections? Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Jürgen Hunold

3:26 p.m.

New subject: [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)

Hi Volodya, Am Mittwoch, 18. Februar 2015, 14:28:48 schrieb Vladimir Prus:

...

On 01/05/2015 10:37 PM, Jürgen Hunold wrote:

...
Unfortunately, we still have Boost.Context open.

Okay, so the problem we're facing is that building master results in:

error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <address-model>32 <architecture>x86

What happens is this:

- Context library is built - It detects default address model and architecture of the current toolchain, and adds those to requirements - Since there's a global dependency on 'headers' target, this pretty much immediately rebuilds everything with new address-model and architecture properties.

Not correct: Boost.Context needs Boost.System so it requires a build with those properties. As they have currently have no defaults, the explicit values differ from the implizit default (none) for both.

...

- We get property set clash

Correct.

...

One way to solve this is to restructure Boost.Context setup so that added properties do not escape. It's doable, but probably will be fragile.

No doubt.

...

Another way is to take libs/context/config, move it to libs/config, and make sure these properties are applied globally. That seems preferable. John, any objections?

I thought the correct way would be to move the architecture detection upwards? We would need something along those lines (from context/bulld/Jamfile.v2) alias select_asm_context_sources : asm_context_sources : [ architecture.architecture ] [ architecture.address-model ] ; in boostcpp.jam in order to detect the architecture everywhere. It would then be helpfull to have sensible default values in order to shorten the generated paths for those defaults. Another solution would be to generate a "header-only" variant of Boost.System and use this nearly everywhere. This would solve *lots* of dependency problems... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! juergen.hunold@gmx.de * voice: 0049 4257 300 ! Fährstraße 1 * fax : 0049 4257 300 ! 31609 Balge/Sebbenhausen * mobil: 0049 178 186 1566 ! Germany

Oliver Kowalke

4:38 p.m.

New subject: [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)

2015-02-18 16:26 GMT+01:00 Jürgen Hunold :

...

Not correct: Boost.Context needs Boost.System so it requires a build with those properties.

boost.context depends on boost.thread (branch master/develop) which itself depends on boost.system

Beman Dawes

5 Jan 5 Jan

1:29 p.m.

New subject: Spam (10.533):Re: [Boost-maint] Conflicts when building libraries at root

On Sun, Jan 4, 2015 at 10:48 AM, Jürgen Hunold wrote:

...

Hi Peter,

Am Sonntag, 4. Januar 2015, 17:06:42 schrieb Peter Dimov:

...
On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get

error: Name clash for 'libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on

When I add --without-context --without-coroutine, I now get

Known issue, see

http://lists.boost.org/boost-build/2014/12/27774.php et. al.

...
Ah. --without-endian. Builds now.

Yes, I've pushed a PR for Boost.Endian in Oktober:

https://github.com/boostorg/endian/pull/7

I've applied one of the suggested resolutions (rename build to benchmark) but the boost-wide b2 build still fails.

The error message is: error: Name clash for 'libboost_system-vc140-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. To get it to work, I have to use: >b2 --without-test --without-context --without-coroutine Here is another b2 build that works:

...

b2 --with-system --with-filesystem --with-timer --with-chrono

But this one fails:

...

b2 --with-system --with-filesystem --with-timer --with-chrono --with-test ... error: Name clash for 'libboost_system-vc140-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>off error: - <asynch-exceptions>on error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.

Note: bin.v2 deleted before each b2 attempt. This fails:

...

b2 --with-system --with-test

but this works:

...

b2 --with-test

That last one builds system, chrono, timer, and test. All with asynch-exceptions-on. I'm at a loss. --Beman

Peter Dimov

1:43 p.m.

New subject: Spam (10.533):Re: [Boost-maint] Conflicts when building libraries at root

Beman Dawes wrote:

...

This fails:

...
b2 --with-system --with-test

but this works:

...
b2 --with-test

That last one builds system, chrono, timer, and test. All with asynch-exceptions-on.

I'm at a loss.

My non-expert explanation is as follows: --with-test builds 'test' and its dependencies (including 'system') with <asynch-exceptions>on. --with-system builds 'system' with <asynch-exceptions>off. --with-system --with-test sees that it would need to build 'system' twice, and since 'system' needs to be copied to stage/lib, it doesn't know which one to copy, as the two have the same name.

Paul A. Bristow

17 Feb 17 Feb

2:58 p.m.

New subject: Spam (10.533):Re: [Boost-maint] Conflicts when building libraries at root

I have come to rebuild my boost libraries from an up-to-date develop branch but find a similar issue. I:\modular-boost>.\b2 --version Boost.Build 2014.03-svn .\bootstrap.bat .\b2 headers .\b2 error: Name clash for 'libboost_system-vc120-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <architecture>x86 << others messages issued. What am I doing wrong? Thanks. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830 I:\modular-boost>.\b2 Building the Boost C++ Libraries. Performing configuration checks - symlinks supported : yes - 32-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - has_icu builds : no (cached) warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - message-compiler : yes (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : no (cached) - long double support : yes (cached) warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: No python installation configured and autoconfiguration note: failed. See http://www.boost.org/libs/python/doc/building.html note: for configuration instructions or pass --without-python to note: suppress this message and silently skip all Boost.Python targets - zlib : no (cached) error: Name clash for 'libboost_system-vc120-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <address-model>32 <architecture>x86 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 05 January 2015 13:44 To: boost@lists.boost.org; boost-maint@lists.boost.org Cc: Boost Developers List Subject: Re: [boost] Spam (10.533):Re: [Boost-maint] Conflicts when building libraries at root

Beman Dawes wrote:

...
This fails:

...
b2 --with-system --with-test

but this works:

...
b2 --with-test

That last one builds system, chrono, timer, and test. All with asynch-exceptions-on.

I'm at a loss.

My non-expert explanation is as follows:

--with-test builds 'test' and its dependencies (including 'system') with <asynch-exceptions>on.

--with-system builds 'system' with <asynch-exceptions>off.

--with-system --with-test sees that it would need to build 'system' twice, and since 'system' needs to be copied to stage/lib, it doesn't know which one to copy, as the two have the same name.

Vladimir Prus

9 Mar 9 Mar

6:56 p.m.

On 01/04/2015 07:06 AM, Peter Dimov wrote:

...

On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get

error: Name clash for 'libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on

All of the patches are supposed to be pushed to devel, and I'd appreciate independent confirmation things build fine with no explicit options. Notes: - you'll have longer paths now, with address model and architecture components. Fixing that is next - it's develop, not master. Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Peter Dimov

8:02 p.m.

Vladimir Prus wrote:

...

All of the patches are supposed to be pushed to devel, and I'd appreciate independent confirmation things build fine with no explicit options.

The Boost.Test problem is still present: error: Name clash for 'libboost_system-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>off error: - <asynch-exceptions>on error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. b2 --without-test toolset=msvc-8.0 starts building, so the context/coroutine problem seems fixed.

Vladimir Prus

8:14 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On 03/09/2015 01:02 PM, Peter Dimov wrote:

...

Vladimir Prus wrote:

...
All of the patches are supposed to be pushed to devel, and I'd appreciate independent confirmation things build fine with no explicit options.

The Boost.Test problem is still present:

error: Name clash for 'libboost_system-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>off error: - <asynch-exceptions>on error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.

b2 --without-test toolset=msvc-8.0 starts building, so the context/coroutine problem seems fixed.

I see, thanks. Naturally Boost.Test problem does not happen to me on Linux, for lacks of asynch-exceptions there. Who of Boost.Test maintainer(s) can explain why this feature is used, and dependency on boost.system? This does not seem like a feature we can globally set? Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Jürgen Hunold

9:03 p.m.

New subject: [test] Re: Conflicts when building libraries at root

Hi Volodya, Am Montag, 9. März 2015, 13:14:48 schrieb Vladimir Prus:

...

I see, thanks. Naturally Boost.Test problem does not happen to me on Linux, for lacks of asynch-exceptions there.

Yes, the same here, unfortunately. And the current regression tests just don't catch this because they don't run the plain "end-user" library builds.

...

Who of Boost.Test maintainer(s) can explain why this feature is used, and dependency on boost.system?

The dependency chain is Boost.Test-> Boost.Timer -> Boost.Chrono -> Boost.System. This propagates "asynch-exceptions" to Boost.System and causes the clash. I've tried to solve this by using the "header-only" variant of Boost.System, but this was only half-hearted and reverted after some hazardous test runs :-(

...

This does not seem like a feature we can globally set?

Perhaps we can, but I'm not an expert in vc exception handling... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Peter Dimov

9:15 p.m.

New subject: [test] Re: Conflicts when building libraries at root

Jürgen Hunold wrote:

...

Am Montag, 9. März 2015, 13:14:48 schrieb Vladimir Prus:

...
This [asynch-exceptions on] does not seem like a feature we can globally set?

Perhaps we can, but I'm not an expert in vc exception handling...

No, I very much would not like everything to be built with asynch-exceptions on, especially since I don't use Boost.Test. "The /EHa compiler option is used to support asynchronous structured exception handling (SEH) with the native C++ catch(...) clause." "Specifying /EHa and attempting to handle all exceptions by using catch(...) can be dangerous. In most cases, asynchronous exceptions are unrecoverable and should be considered fatal. Catching them and proceeding can cause process corruption and lead to bugs that are hard to find and fix." https://msdn.microsoft.com/en-us/library/1deeycx5.aspx

Andrey Semashev

9:24 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On Monday 09 March 2015 23:15:16 Peter Dimov wrote:

...

Jürgen Hunold wrote:

...
Am Montag, 9. März 2015, 13:14:48 schrieb Vladimir Prus:

...
This [asynch-exceptions on] does not seem like a feature we can

globally set?

Perhaps we can, but I'm not an expert in vc exception handling...

No, I very much would not like everything to be built with asynch-exceptions on.

+1, SEH should be done explicitly where required and not mixed up with C++ exceptions.

Vladimir Prus

9:34 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On 03/09/2015 02:24 PM, Andrey Semashev wrote:

...

On Monday 09 March 2015 23:15:16 Peter Dimov wrote:

...
Jürgen Hunold wrote:

...
Am Montag, 9. März 2015, 13:14:48 schrieb Vladimir Prus:

...
This [asynch-exceptions on] does not seem like a feature we can

globally set?

Perhaps we can, but I'm not an expert in vc exception handling...

No, I very much would not like everything to be built with asynch-exceptions on.

+1, SEH should be done explicitly where required and not mixed up with C++ exceptions.

So why is Boost.Test enabling those? Are there any particular files in Boost.Test that need it? If so, we can change Jamfile to only compile those files with asynch exceptions, without propagating it to dependencies. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Gavin Lambert

10:25 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On 10/03/2015 10:34, Vladimir Prus wrote:

...

On 03/09/2015 02:24 PM, Andrey Semashev wrote:

...
On Monday 09 March 2015 23:15:16 Peter Dimov wrote:

...
Jürgen Hunold wrote:

...
Am Montag, 9. März 2015, 13:14:48 schrieb Vladimir Prus:

...
This [asynch-exceptions on] does not seem like a feature we can globally set?

Perhaps we can, but I'm not an expert in vc exception handling...

No, I very much would not like everything to be built with asynch-exceptions on.

+1, SEH should be done explicitly where required and not mixed up with C++ exceptions.

So why is Boost.Test enabling those? Are there any particular files in Boost.Test that need it?

I haven't looked at the code, but I suspect it is so that it can intercept such faults (eg. null pointer dereferences) and translate them into test failures. _set_se_translator can be used to automatically convert SEH exceptions into a specific C++ exception (which is better than using catch(...)), but /EHa must be enabled on the code where the exception is thrown in order to get an accurate location.

Vladimir Prus

10:28 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On 03/09/2015 03:25 PM, Gavin Lambert wrote:

...

On 10/03/2015 10:34, Vladimir Prus wrote:

...
On 03/09/2015 02:24 PM, Andrey Semashev wrote:

...
On Monday 09 March 2015 23:15:16 Peter Dimov wrote:

...
Jürgen Hunold wrote:

...
Am Montag, 9. März 2015, 13:14:48 schrieb Vladimir Prus:

...
This [asynch-exceptions on] does not seem like a feature we can globally set?

Perhaps we can, but I'm not an expert in vc exception handling...

No, I very much would not like everything to be built with asynch-exceptions on.

+1, SEH should be done explicitly where required and not mixed up with C++ exceptions.

So why is Boost.Test enabling those? Are there any particular files in Boost.Test that need it?

I haven't looked at the code, but I suspect it is so that it can intercept such faults (eg. null pointer dereferences) and translate them into test failures.

_set_se_translator can be used to automatically convert SEH exceptions into a specific C++ exception (which is better than using catch(...)), but /EHa must be enabled on the code where the exception is thrown in order to get an accurate location.

Thanks for explanation! So if that's about code where the exception is *thrown*, it would seem Boost.Test should not need to set this option on itself? It would be up to users to either enable that mode if they want Boost.Test to report SEH exceptions, or not do that. Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Andrey Semashev

10:39 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On Tuesday 10 March 2015 11:25:30 Gavin Lambert wrote:

...

On 10/03/2015 10:34, Vladimir Prus wrote:

...
On 03/09/2015 02:24 PM, Andrey Semashev wrote:

...
On Monday 09 March 2015 23:15:16 Peter Dimov wrote:

...
Jürgen Hunold wrote:

...
Am Montag, 9. März 2015, 13:14:48 schrieb Vladimir Prus:

...
This [asynch-exceptions on] does not seem like a feature we can

globally set?

Perhaps we can, but I'm not an expert in vc exception handling...

No, I very much would not like everything to be built with asynch-exceptions on.

+1, SEH should be done explicitly where required and not mixed up with C++ exceptions.

So why is Boost.Test enabling those? Are there any particular files in Boost.Test that need it?

I haven't looked at the code, but I suspect it is so that it can intercept such faults (eg. null pointer dereferences) and translate them into test failures.

_set_se_translator can be used to automatically convert SEH exceptions into a specific C++ exception (which is better than using catch(...)), but /EHa must be enabled on the code where the exception is thrown in order to get an accurate location.

I can see some explicit SEH in execution_monitor, and a cursory look through catch(...) didn't reveal places which looked like they're supposed to deal with structured exceptions. I didn't look deep though. The option appeared back in 2005 [1], it refers to the minimal Boost.Test. Currently, minimal.hpp uses execution_monitor to run the tests, so the compiler option may very well be outdated now. I say we remove it and see what happens. [1] https://github.com/boostorg/test/commit/e7502ce9b9a4fcb789ef8ca05a5dfd87da1d...

Gennadiy Rozental

11:22 p.m.

New subject: [test] Re: Conflicts when building libraries at root

Vladimir Prus writes:

...

So why is Boost.Test enabling those? Are there any particular files in Boost.Test that need it? If so, we can change Jamfile to only compile those files with asynch exceptions, without propagating it to dependencies.

I am sure execution_monitor.cpp needs it. Frankly I do not remember for sure at this point, but I thought all the components of the test module will need to be built with /EHa for Boost.Test to be able to catch SEH successfully. What is the problem we are trying to solve?

Vladimir Prus

10 Mar 10 Mar

4:44 a.m.

New subject: [test] Re: Conflicts when building libraries at root

On 03/09/2015 04:22 PM, Gennadiy Rozental wrote:

...

Vladimir Prus writes:

...
So why is Boost.Test enabling those? Are there any particular files in Boost.Test that need it? If so, we can change Jamfile to only compile those files with asynch exceptions, without propagating it to dependencies.

I am sure execution_monitor.cpp needs it. Frankly I do not remember for sure at this point, but I thought all the components of the test module will need to be built with /EHa for Boost.Test to be able to catch SEH successfully.

What is the problem we are trying to solve?

The problem is that due to Boost.Test-> Boost.Timer -> Boost.Chrono -> Boost.System dependency chain - which has asynch-exceptions=on, this effectively requests Boost.System to be built and installed with asynch-exceptions=on. On the other hand, top-level build requests Boost.System without asynch-exceptions. As result, build of develop just fails since we can't install Boost.System with two different properties. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Gennadiy Rozental

8:53 a.m.

New subject: [test] Re: Conflicts when building libraries at root

Vladimir Prus writes:

...

The problem is that due to

Boost.Test-> Boost.Timer -> Boost.Chrono -> Boost.System

dependency chain - which has asynch-exceptions=on, this effectively requests Boost.System to be built and installed with asynch-exceptions=on. On the other hand, top-level build requests Boost.System without asynch-exceptions. As result, build of develop just fails since we can't install Boost.System with two different properties.

I think we need dependency other way around. boost.Test itself needs to be build with /EHa and everything which depends on it needs it. All that Boost.Test depends on can be built with out /EHa (we won't be able to report error in these libs, but have none there, right ;o) ) Gennadiy

Vladimir Prus

11 Mar 11 Mar

5:56 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On 03/10/2015 01:53 AM, Gennadiy Rozental wrote:

...

Vladimir Prus writes:

...
The problem is that due to

Boost.Test-> Boost.Timer -> Boost.Chrono -> Boost.System

dependency chain - which has asynch-exceptions=on, this effectively requests Boost.System to be built and installed with asynch-exceptions=on. On the other hand, top-level build requests Boost.System without asynch-exceptions. As result, build of develop just fails since we can't install Boost.System with two different properties.

I think we need dependency other way around. boost.Test itself needs to be build with /EHa and everything which depends on it needs it. All that Boost.Test depends on can be built with out /EHa (we won't be able to report error in these libs, but have none there, right ;o) )

Could we split the question in two? First, you say that current direction of dependency is not necessary, and further, it breaks builds. Shall I remove asynch-exceptions requirement then? Second, you suggest that clients of Boost.Test should be forced, or suggested to, enable asynch-exceptions. I don't have an opinion on the essence of this suggestion, I'd just point out that: - We have no control of code outside of Boost - I'm not sure maintainers of other libraries that use Boost.Test would want to build with asynch-exceptions In other words, this second question appears to be fairly complicated, and can't be solved in time for this release for sure, and would have somebody to push for it. So, I'll just implement solution for the first question, OK? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Jürgen Hunold

6:34 p.m.

New subject: [test] Re: Conflicts when building libraries at root

HI Voloday Am Mittwoch, 11. März 2015, 10:56:39 schrieb Vladimir Prus:

...

In other words, this second question appears to be fairly complicated, and can't be solved in time for this release for sure, and would have somebody to push for it.

Please note that the dependency on Boost.System is _only_ on develop, not on master. The last merge to master was 3 years ago. Which is another story... So we should go forward and merge the existing patches to master and leave Boost.Test for later. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Vladimir Prus

6:36 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On 03/11/2015 11:34 AM, Jürgen Hunold wrote:

...

HI Voloday

Am Mittwoch, 11. März 2015, 10:56:39 schrieb Vladimir Prus:

...
In other words, this second question appears to be fairly complicated, and can't be solved in time for this release for sure, and would have somebody to push for it.

Please note that the dependency on Boost.System is _only_ on develop, not on master. The last merge to master was 3 years ago. Which is another story...

It seems that develop not building out of box on Windows is an important issue.

...

So we should go forward and merge the existing patches to master and leave Boost.Test for later.

The beta is coming out without these fixes, I'll merge them for final release. -- Vladimir Prus CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software/

Jürgen Hunold

7 p.m.

New subject: [test] Re: Conflicts when building libraries at root

Hi Volodya, On Mittwoch, 11. März 2015 11:36:01 Vladimir Prus wrote:

...

On 03/11/2015 11:34 AM, Jürgen Hunold wrote:

...
Please note that the dependency on Boost.System is _only_ on develop, not on master. The last merge to master was 3 years ago. Which is another story... It seems that develop not building out of box on Windows is an important issue.

<rant> Well, develop did not build out-of-the-box for what, the last 4 months? And suddenly it is more important than fixing master? </rant> The real issue is that the regression tests did not capture this because they don't run the "bootstrap.{sh|bat} ; b2" "end-user build" sequence at all. And my reports, others reports and my replies were obviously ignored, so Boost.Context even got merged to master causing the same failure. Sorry, I can't do much more than regularly (read: daily) building boost develop and reporting bugs for the foreseeable future. I'd really appreciate it if someone would enhance "run.py" to run the end-user build sequence first and bail out with bells and whistles if that don't work. This would have prevented us from getting into this mess in the first place. It is quite ironic that the lack of merge to master for Boost.Test is saving some work right now.

...

...
So we should go forward and merge the existing patches to master and leav> Boost.Test for later.

The beta is coming out without these fixes, I'll merge them for final release.

I'm fine with this. Only make sure you have a *big* note on how to build the binaries in the announcement. And are prepared to handle the complaints from those who will just don't get it. Still quite upset, Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Vladimir Prus

8:40 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On 03/11/2015 12:00 PM, Jürgen Hunold wrote:

...

Hi Volodya,

On Mittwoch, 11. März 2015 11:36:01 Vladimir Prus wrote:

...
On 03/11/2015 11:34 AM, Jürgen Hunold wrote:

...
Please note that the dependency on Boost.System is _only_ on develop, not on master. The last merge to master was 3 years ago. Which is another story... It seems that develop not building out of box on Windows is an important issue.

<rant> Well, develop did not build out-of-the-box for what, the last 4 months? And suddenly it is more important than fixing master? </rant>

The real issue is that the regression tests did not capture this because they don't run the "bootstrap.{sh|bat} ; b2" "end-user build" sequence at all. And my reports, others reports and my replies were obviously ignored, so Boost.Context even got merged to master causing the same failure. Sorry, I can't do much more than regularly (read: daily) building boost develop and reporting bugs for the foreseeable future. I'd really appreciate it if someone would enhance "run.py" to run the end-user build sequence first and bail out with bells and whistles if that don't work. This would have prevented us from getting into this mess in the first place.

That's a valid point, and I understand why you would be upset. I've asked release managers what technical solutions we could use; it would be great if we could get notification of failed builds faster than the current builds turnaround - e.g. if we could just use Jenkins or similar.

...

It is quite ironic that the lack of merge to master for Boost.Test is saving some work right now.

...
...
So we should go forward and merge the existing patches to master and leav> Boost.Test for later.

The beta is coming out without these fixes, I'll merge them for final release.

I'm fine with this. Only make sure you have a *big* note on how to build the binaries in the announcement. And are prepared to handle the complaints from those who will just don't get it.

Not-happy-about-this-either-yours, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Vladimir Prus

10:03 p.m.

New subject: [test] Re: Conflicts when building libraries at root

On 03/11/2015 01:40 PM, Vladimir Prus wrote:

...

...
The real issue is that the regression tests did not capture this because they don't run the "bootstrap.{sh|bat} ; b2" "end-user build" sequence at all. And my reports, others reports and my replies were obviously ignored, so Boost.Context even got merged to master causing the same failure. Sorry, I can't do much more than regularly (read: daily) building boost develop and reporting bugs for the foreseeable future. I'd really appreciate it if someone would enhance "run.py" to run the end-user build sequence first and bail out with bells and whistles if that don't work. This would have prevented us from getting into this mess in the first place.

That's a valid point, and I understand why you would be upset. I've asked release managers what technical solutions we could use; it would be great if we could get notification of failed builds faster than the current builds turnaround - e.g. if we could just use Jenkins or similar.

Ok, we now have some solution. This job: https://travis-ci.org/boostorg/boost is supposed to be triggered on any superproject commit and does "./bootstrap.sh; ./b2 -n" on Linux, so it should detect total build failures. It's still unclear who to setup email notification so that they go to the original author, not the bot that updates superproject. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Jürgen Hunold

13 Mar 13 Mar

7:14 a.m.

New subject: [test] Re: Conflicts when building libraries at root

Hi Volodya, Am Mittwoch, 11. März 2015, 15:03:54 schrieb Vladimir Prus:

...

On 03/11/2015 01:40 PM, Vladimir Prus wrote:

...
That's a valid point, and I understand why you would be upset. I've asked release managers what technical solutions we could use; it would be great if we could get notification of failed builds faster than the current builds turnaround - e.g. if we could just use Jenkins or similar.

Well, the tool itself does not change anything.

...

Ok, we now have some solution. This job:

https://travis-ci.org/boostorg/boost

is supposed to be triggered on any superproject commit and does "./bootstrap.sh; ./b2 -n" on Linux, so it should detect total build failures.

Okay, that is better than nothing. Does it does not work on my fork for creating PRs unfortunately. Investigating this. But that still won't catch the "asynch-exceptions=on" Boost.Test case on windows. So we still have a long way to go. Thanks for implementing this.

...

It's still unclear who to setup email notification so that they go to the original author, not the bot that updates superproject.

Yes, that is unfortunate. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Peter Dimov

9 Mar 9 Mar

8:18 p.m.

...

b2 --without-test toolset=msvc-8.0 starts building, so the context/coroutine problem seems fixed.

It builds mostly everything except Boost.Log gives a few thousand warnings of the form compile-c-c++ bin.v2\libs\log\build\msvc-8.0\debug\address-model-32\architecture -x86\build-no\link-static\log-api-winnt\threading-multi\matches_relation_factory .obj matches_relation_factory.cpp .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_EMPTY' .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_BEGIN_PARENS' .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_DETAIL_IS_EMPTY_PROCESS' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_EMPTY' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_BEGIN_PARENS' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_DETAIL_IS_EMPTY_PROCESS' and type_erasure fails with compile-c-c++ bin.v2\libs\type_erasure\build\msvc-8.0\release\address-model-32\a rchitecture-x86\link-static\threading-multi\dynamic_binding.obj dynamic_binding.cpp C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(32) : error C2248: 'boost::shared_mutex::shared_mutex' : cannot access private member declar ed in class 'boost::shared_mutex' .\boost/thread/win32/shared_mutex.hpp(87) : see declaration of 'boost::s hared_mutex::shared_mutex' .\boost/thread/win32/shared_mutex.hpp(28) : see declaration of 'boost::s hared_mutex' C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(30) : while compiling class template member function 'std::pair<_Ty1,_Ty2>::pair(voi d)' with [ _Ty1=`anonymous-namespace'::map_type, _Ty2=`anonymous-namespace'::mutex_type ] libs\type_erasure\src\dynamic_binding.cpp(30) : see reference to class t emplate instantiation 'std::pair<_Ty1,_Ty2>' being compiled with [ _Ty1=`anonymous-namespace'::map_type, _Ty2=`anonymous-namespace'::mutex_type ] but this is not a Boost.Build's problem. :-)

Edward Diener

8:58 p.m.

On 3/9/2015 4:18 PM, Peter Dimov wrote:

...

...
b2 --without-test toolset=msvc-8.0 starts building, so the context/coroutine problem seems fixed.

It builds mostly everything except Boost.Log gives a few thousand warnings of the form

compile-c-c++ bin.v2\libs\log\build\msvc-8.0\debug\address-model-32\architecture -x86\build-no\link-static\log-api-winnt\threading-multi\matches_relation_factory

.obj matches_relation_factory.cpp .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_EMPTY' .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_BEGIN_PARENS' .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_DETAIL_IS_EMPTY_PROCESS' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_EMPTY' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_BEGIN_PARENS' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_DETAIL_IS_EMPTY_PROCESS'

VC++ 8.0 ( VS2005 ) is noticeable, even among the non-standard VC++ preprocessors, for being poorer than even VC++ 9, VC++ 10, VC++11, and VC++12. So the warnings are to be expected.

...

and type_erasure fails with

compile-c-c++ bin.v2\libs\type_erasure\build\msvc-8.0\release\address-model-32\a rchitecture-x86\link-static\threading-multi\dynamic_binding.obj dynamic_binding.cpp C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(32) : error C2248: 'boost::shared_mutex::shared_mutex' : cannot access private member declar ed in class 'boost::shared_mutex' .\boost/thread/win32/shared_mutex.hpp(87) : see declaration of 'boost::s hared_mutex::shared_mutex' .\boost/thread/win32/shared_mutex.hpp(28) : see declaration of 'boost::s hared_mutex' C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE\utility(30) : while compiling class template member function 'std::pair<_Ty1,_Ty2>::pair(voi d)' with [ _Ty1=`anonymous-namespace'::map_type, _Ty2=`anonymous-namespace'::mutex_type ] libs\type_erasure\src\dynamic_binding.cpp(30) : see reference to class t emplate instantiation 'std::pair<_Ty1,_Ty2>' being compiled with [ _Ty1=`anonymous-namespace'::map_type, _Ty2=`anonymous-namespace'::mutex_type ]

but this is not a Boost.Build's problem. :-)

Andrey Semashev

9:09 p.m.

On Mon, Mar 9, 2015 at 11:58 PM, Edward Diener wrote:

...

On 3/9/2015 4:18 PM, Peter Dimov wrote:

...
...
b2 --without-test toolset=msvc-8.0 starts building, so the context/coroutine problem seems fixed.

It builds mostly everything except Boost.Log gives a few thousand warnings of the form

compile-c-c++ bin.v2\libs\log\build\msvc-8.0\debug\address-model-32\architecture

-x86\build-no\link-static\log-api-winnt\threading-multi\matches_relation_factory

.obj matches_relation_factory.cpp .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_EMPTY' .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_BEGIN_PARENS' .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_DETAIL_IS_EMPTY_PROCESS' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_EMPTY' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_BEGIN_PARENS' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_DETAIL_IS_EMPTY_PROCESS'

VC++ 8.0 ( VS2005 ) is noticeable, even among the non-standard VC++ preprocessors, for being poorer than even VC++ 9, VC++ 10, VC++11, and VC++12. So the warnings are to be expected.

There weren't any warnings before. Is this a result of a change in Boost.PP?

Edward Diener

10:20 p.m.

On 3/9/2015 5:09 PM, Andrey Semashev wrote:

...

On Mon, Mar 9, 2015 at 11:58 PM, Edward Diener wrote:

...
On 3/9/2015 4:18 PM, Peter Dimov wrote:

...
...
b2 --without-test toolset=msvc-8.0 starts building, so the context/coroutine problem seems fixed.

It builds mostly everything except Boost.Log gives a few thousand warnings of the form

compile-c-c++ bin.v2\libs\log\build\msvc-8.0\debug\address-model-32\architecture

-x86\build-no\link-static\log-api-winnt\threading-multi\matches_relation_factory

.obj matches_relation_factory.cpp .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_EMPTY' .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_BEGIN_PARENS' .\boost/phoenix/support/preprocessed/vector_10.hpp(47) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_DETAIL_IS_EMPTY_PROCESS' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_EMPTY' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_IS_BEGIN_PARENS' .\boost/phoenix/support/preprocessed/vector_10.hpp(78) : warning C4003: not enou gh actual parameters for macro 'BOOST_PP_DETAIL_IS_EMPTY_PROCESS'

VC++ 8.0 ( VS2005 ) is noticeable, even among the non-standard VC++ preprocessors, for being poorer than even VC++ 9, VC++ 10, VC++11, and VC++12. So the warnings are to be expected.

There weren't any warnings before. Is this a result of a change in Boost.PP?

Yes, but they were already in 1.57. The changes added some new (BOOST_PP_IS_BEGIN_PARENS) and better functionality (the internal BOOST_PP_IS_EMPTY) to Boost PP, as well as fixing some corner cases with VC++ I discovered when testing VMD. Turning off C4003 globally for VC++ is the only solution to the VC++ warnings I could ever discover. I attempted to turn off the warnings in the macros where they occur, but VC++ just ignores that. Evidently the warnings can only be turned off globally or possibly at the very top-level macro which eventually causes them.

Damien Buhl

10 Mar 10 Mar

5:54 a.m.

On 09/03/2015 23:20, Edward Diener wrote:

...

On 3/9/2015 5:09 PM, Andrey Semashev wrote: [...]

...
There weren't any warnings before. Is this a result of a change in Boost.PP?

Yes, but they were already in 1.57. The changes added some new (BOOST_PP_IS_BEGIN_PARENS) and better functionality (the internal BOOST_PP_IS_EMPTY) to Boost PP, as well as fixing some corner cases with VC++ I discovered when testing VMD.

The reason why this happens more in this build, is that the new BOOST_FUSION_ADAPT macros uses BOOST_PP_IS_EMPTY for each field member now. This is used to determine if the type was provided or has to be deduced. In all the test I ran I got no warning under VC++, but this was on a pretty new version. And some of my test were run before 1.57.

...

Turning off C4003 globally for VC++ is the only solution to the VC++ warnings I could ever discover. I attempted to turn off the warnings in the macros where they occur, but VC++ just ignores that. Evidently the warnings can only be turned off globally or possibly at the very top-level macro which eventually causes them.

Do you think I could add specific pragmas to disable C4003 where I use BOOST_PP_IS_EMPTY ?

Andrey Semashev

8:08 a.m.

On Tuesday 10 March 2015 06:54:30 Damien Buhl wrote:

...

On 09/03/2015 23:20, Edward Diener wrote:

...
On 3/9/2015 5:09 PM, Andrey Semashev wrote: [...]

...
There weren't any warnings before. Is this a result of a change in Boost.PP?

Yes, but they were already in 1.57. The changes added some new (BOOST_PP_IS_BEGIN_PARENS) and better functionality (the internal BOOST_PP_IS_EMPTY) to Boost PP, as well as fixing some corner cases with VC++ I discovered when testing VMD.

The reason why this happens more in this build, is that the new BOOST_FUSION_ADAPT macros uses BOOST_PP_IS_EMPTY for each field member now. This is used to determine if the type was provided or has to be deduced.

Is it possible to avoid BOOST_PP_IS_EMPTY? For example, use a keyword instead of testing for an empty string?

...

...
Turning off C4003 globally for VC++ is the only solution to the VC++ warnings I could ever discover. I attempted to turn off the warnings in the macros where they occur, but VC++ just ignores that. Evidently the warnings can only be turned off globally or possibly at the very top-level macro which eventually causes them.

Do you think I could add specific pragmas to disable C4003 where I use BOOST_PP_IS_EMPTY ?

I suspect pragmas should envelop the place where the macro unfolds. In this case it's Boost.Phoenix. But in general this is user's code. And __pragma is not available in MSVC 8.

Damien Buhl

10:23 a.m.

On 10/03/2015 09:08, Andrey Semashev wrote:

...

On Tuesday 10 March 2015 06:54:30 Damien Buhl wrote:

...
On 09/03/2015 23:20, Edward Diener wrote:

...
On 3/9/2015 5:09 PM, Andrey Semashev wrote: [...]

...
There weren't any warnings before. Is this a result of a change in Boost.PP?

Yes, but they were already in 1.57. The changes added some new (BOOST_PP_IS_BEGIN_PARENS) and better functionality (the internal BOOST_PP_IS_EMPTY) to Boost PP, as well as fixing some corner cases with VC++ I discovered when testing VMD.

The reason why this happens more in this build, is that the new BOOST_FUSION_ADAPT macros uses BOOST_PP_IS_EMPTY for each field member now. This is used to determine if the type was provided or has to be deduced.

Is it possible to avoid BOOST_PP_IS_EMPTY? For example, use a keyword instead of testing for an empty string?

I'll change this to look at the implication that it has. Not sure it will be better on old compilers like MSVC 8, but perhaps we can avoid some warnings. :p What is good is that the current code allow this change easily. Because when BOOST_PP_VARIADICS support is active, it wouldn't be needed at all, and when it's not there then it currently only uses BOOST_PP_IS_EMPTY to check if the provided type is a macro which expands to BOOST_PP_EMPTY, namely BOOST_FUSION_ADAPT_AUTO. So it might be quite easy to replace it to make a check if the provided type is a string equal to BOOST_FUSION_ADAPT_AUTO. Actually it makes even more sense than the check for emptiness. The only disadvandtage is that the user cannot anymore write nothing instead of the type when he don't have BOOST_PP_VARIADICS support (which is anyway undocumented and not advised). Otherwise isn't there any possibility to fix the warnings in BOOST_PP_IS_EMPTY? Because the old version of BOOST_PP_IS_EMPTY didn't warn about anything AFAIK when used with a parameter which expands to BOOST_PP_EMPTY().

...

...
...
Turning off C4003 globally for VC++ is the only solution to the VC++ warnings I could ever discover. I attempted to turn off the warnings in the macros where they occur, but VC++ just ignores that. Evidently the warnings can only be turned off globally or possibly at the very top-level macro which eventually causes them.

Do you think I could add specific pragmas to disable C4003 where I use BOOST_PP_IS_EMPTY ?

I suspect pragmas should envelop the place where the macro unfolds. In this case it's Boost.Phoenix. But in general this is user's code. And __pragma is not available in MSVC 8.

ok thanks for the info.

Edward Diener

2:55 p.m.

On 3/10/2015 6:23 AM, Damien Buhl wrote:

...

On 10/03/2015 09:08, Andrey Semashev wrote:

...
On Tuesday 10 March 2015 06:54:30 Damien Buhl wrote:

...
On 09/03/2015 23:20, Edward Diener wrote:

...
On 3/9/2015 5:09 PM, Andrey Semashev wrote: [...]

...
There weren't any warnings before. Is this a result of a change in Boost.PP?

Yes, but they were already in 1.57. The changes added some new (BOOST_PP_IS_BEGIN_PARENS) and better functionality (the internal BOOST_PP_IS_EMPTY) to Boost PP, as well as fixing some corner cases with VC++ I discovered when testing VMD.

The reason why this happens more in this build, is that the new BOOST_FUSION_ADAPT macros uses BOOST_PP_IS_EMPTY for each field member now. This is used to determine if the type was provided or has to be deduced.

Is it possible to avoid BOOST_PP_IS_EMPTY? For example, use a keyword instead of testing for an empty string?

I'll change this to look at the implication that it has. Not sure it will be better on old compilers like MSVC 8, but perhaps we can avoid some warnings. :p

What is good is that the current code allow this change easily. Because when BOOST_PP_VARIADICS support is active, it wouldn't be needed at all, and when it's not there then it currently only uses BOOST_PP_IS_EMPTY to check if the provided type is a macro which expands to BOOST_PP_EMPTY, namely BOOST_FUSION_ADAPT_AUTO.

So it might be quite easy to replace it to make a check if the provided type is a string equal to BOOST_FUSION_ADAPT_AUTO. Actually it makes even more sense than the check for emptiness.

The only disadvandtage is that the user cannot anymore write nothing instead of the type when he don't have BOOST_PP_VARIADICS support (which is anyway undocumented and not advised).

Otherwise isn't there any possibility to fix the warnings in BOOST_PP_IS_EMPTY? Because the old version of BOOST_PP_IS_EMPTY didn't warn about anything AFAIK when used with a parameter which expands to BOOST_PP_EMPTY().

If you are compiling with VC++ then BOOST_PP_VARIADICS is on by default. Try to specifically turn it off to see if the warnings go away if that is an option. Of course with BOOST_PP_VARIADICS off the variadic support in Boost PP goes away.

Andrey Semashev

2:59 p.m.

On Tuesday 10 March 2015 10:55:43 Edward Diener wrote:

...

If you are compiling with VC++ then BOOST_PP_VARIADICS is on by default.

Does MSVC 8 actually support variadic macros?

Edward Diener

3:20 p.m.

On 3/10/2015 10:59 AM, Andrey Semashev wrote:

...

On Tuesday 10 March 2015 10:55:43 Edward Diener wrote:

...
If you are compiling with VC++ then BOOST_PP_VARIADICS is on by default.

Does MSVC 8 actually support variadic macros?

Yes. _MSC_VER 1400 on up supports variadic macros.

Edward Diener

2:44 p.m.

On 3/10/2015 4:08 AM, Andrey Semashev wrote:

...

On Tuesday 10 March 2015 06:54:30 Damien Buhl wrote:

...
On 09/03/2015 23:20, Edward Diener wrote:

...
On 3/9/2015 5:09 PM, Andrey Semashev wrote: [...]

...
There weren't any warnings before. Is this a result of a change in Boost.PP?

Yes, but they were already in 1.57. The changes added some new (BOOST_PP_IS_BEGIN_PARENS) and better functionality (the internal BOOST_PP_IS_EMPTY) to Boost PP, as well as fixing some corner cases with VC++ I discovered when testing VMD.

The reason why this happens more in this build, is that the new BOOST_FUSION_ADAPT macros uses BOOST_PP_IS_EMPTY for each field member now. This is used to determine if the type was provided or has to be deduced.

Is it possible to avoid BOOST_PP_IS_EMPTY? For example, use a keyword instead of testing for an empty string?

...
...
Turning off C4003 globally for VC++ is the only solution to the VC++ warnings I could ever discover. I attempted to turn off the warnings in the macros where they occur, but VC++ just ignores that. Evidently the warnings can only be turned off globally or possibly at the very top-level macro which eventually causes them.

Do you think I could add specific pragmas to disable C4003 where I use BOOST_PP_IS_EMPTY ?

I suspect pragmas should envelop the place where the macro unfolds. In this case it's Boost.Phoenix. But in general this is user's code. And __pragma is not available in MSVC 8.

I tried __pragma within the affected Boost PP macros for VC++ for the C4003 warnings but the VC++ preprocessor thinks it is macro code and cannot process it. I know the documentation claims that it works but I could never get it to do so when using Boost PP.

Peter Dimov

1:05 p.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

Damien Buhl wrote:

...

In all the test I ran I got no warning under VC++, but this was on a pretty new version. And some of my test were run before 1.57.

It probably depends on the VC++ version. 8.0 and 10.0 warn, 11.0 and 12.0 (I think) do not.

Damien Buhl

11 Mar 11 Mar

7:11 a.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On 10/03/2015 14:05, Peter Dimov wrote:

...

Damien Buhl wrote:

...
In all the test I ran I got no warning under VC++, but this was on a pretty new version. And some of my test were run before 1.57.

It probably depends on the VC++ version. 8.0 and 10.0 warn, 11.0 and 12.0 (I think) do not.

Yes that's for sure the point. I'm just quoting the mail from Edward Diener from the other thread here, so that we get a separate thread for this point. On 10/03/2015 15:36, Edward Diener wrote:

...

[...] The BOOST_PP_IS_EMPTY macro is undocumented in Boost PP and therefore was not meant to be used outside the library. I actually changed it to be much more reliable when using variadic macros, but unfortunately that mean that VC++ puts out more spurious warning messages.

Oh sorry, I wouldn't have used it if I had known, I used it because it was in the top-level include path aside other things I used ( i.e. boost/preprocessor/facilities/is_empty.hpp), and therefore thought it might be used. But I agree that I should have checked in the documentation. I'll fix this, I can remove the check for emptiness, as I don't really present it's usage in the doc. I documented that in the case the people don't have BOOST_PP_VARIADICS, they can use BOOST_FUSION_ADAPT_AUTO instead of the type. Like this : // With BOOST_PP_VARIADICS support : BOOST_FUSION_ADAPT_STRUCT( demo::employee, name, age) // Without BOOST_PP_VARIADICS support : BOOST_FUSION_ADAPT_STRUCT( demo::employee, (BOOST_FUSION_ADAPT_AUTO, name) (BOOST_FUSION_ADAPT_AUTO, age) ) Both signatures works on BOOST_PP_VARIADICS enabled compilers. Actually BOOST_FUSION_ADAPT_AUTO expands to BOOST_PP_EMPTY(). So I will change BOOST_FUSION_ADAPT_AUTO to some constant other than emptiness and check if it equals. These should not provide any warning anymore even on VC++ 8.0. I should be able to have a fix this evening.

...

Honestly just getting VC++ to work properly in Boost PP and VMD is hard enough. Fixing VC++ warning messages, when there is nothing wrong, is nearly impossible. I understand they are irritating but they are totally false also. They are part of VC++'s non-conformant C++ preprocessor.

I would also agree to live with the warnings in such old non-conformant compilers, but as there is another way in my code, I'll use it, so that it get better everywhere. :)

Andrey Semashev

7:18 a.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On Wed, Mar 11, 2015 at 10:11 AM, Damien Buhl wrote:

...

// Without BOOST_PP_VARIADICS support : BOOST_FUSION_ADAPT_STRUCT( demo::employee, (BOOST_FUSION_ADAPT_AUTO, name) (BOOST_FUSION_ADAPT_AUTO, age) )

Both signatures works on BOOST_PP_VARIADICS enabled compilers. Actually BOOST_FUSION_ADAPT_AUTO expands to BOOST_PP_EMPTY().

Perhaps, 'auto' would be shorter? BOOST_FUSION_ADAPT_STRUCT( demo::employee, (auto, name) (auto, age) ) It also looks kind of similar to C++14 lambdas.

...

So I will change BOOST_FUSION_ADAPT_AUTO to some constant other than emptiness and check if it equals. These should not provide any warning anymore even on VC++ 8.0.

I should be able to have a fix this evening.

Thanks. I currently disabled the warning locally in Boost.Log but I'd rather not have to do that. It also doesn't fix warnings in users' code.

Damien Buhl

7:29 a.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On 11/03/2015 08:18, Andrey Semashev wrote:

...

On Wed, Mar 11, 2015 at 10:11 AM, Damien Buhl wrote:

...
// Without BOOST_PP_VARIADICS support : BOOST_FUSION_ADAPT_STRUCT( demo::employee, (BOOST_FUSION_ADAPT_AUTO, name) (BOOST_FUSION_ADAPT_AUTO, age) )

Both signatures works on BOOST_PP_VARIADICS enabled compilers. Actually BOOST_FUSION_ADAPT_AUTO expands to BOOST_PP_EMPTY().

Perhaps, 'auto' would be shorter?

BOOST_FUSION_ADAPT_STRUCT( demo::employee, (auto, name) (auto, age) )

It also looks kind of similar to C++14 lambdas. That looks nice, and it may be great, but I'm a bit concerned in giving a slight different meaning than the official one to a standard keyword.

...

...
So I will change BOOST_FUSION_ADAPT_AUTO to some constant other than emptiness and check if it equals. These should not provide any warning anymore even on VC++ 8.0.

I should be able to have a fix this evening.

Thanks. I currently disabled the warning locally in Boost.Log but I'd rather not have to do that. It also doesn't fix warnings in users' code.

Thanks for the temporary fix. I'll do my best to avoid these warnings.

Andrey Semashev

7:49 a.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On Wed, Mar 11, 2015 at 10:29 AM, Damien Buhl wrote:

...

On 11/03/2015 08:18, Andrey Semashev wrote:

...
On Wed, Mar 11, 2015 at 10:11 AM, Damien Buhl wrote:

...
// Without BOOST_PP_VARIADICS support : BOOST_FUSION_ADAPT_STRUCT( demo::employee, (BOOST_FUSION_ADAPT_AUTO, name) (BOOST_FUSION_ADAPT_AUTO, age) )

Both signatures works on BOOST_PP_VARIADICS enabled compilers. Actually BOOST_FUSION_ADAPT_AUTO expands to BOOST_PP_EMPTY().

Perhaps, 'auto' would be shorter?

BOOST_FUSION_ADAPT_STRUCT( demo::employee, (auto, name) (auto, age) )

It also looks kind of similar to C++14 lambdas.

That looks nice, and it may be great, but I'm a bit concerned in giving a slight different meaning than the official one to a standard keyword.

Could you describe the difference?

Damien Buhl

17 Mar 17 Mar

9:23 a.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On 11/03/2015 08:49, Andrey Semashev wrote:

...

On Wed, Mar 11, 2015 at 10:29 AM, Damien Buhl wrote: [...]

...
...
Perhaps, 'auto' would be shorter?

BOOST_FUSION_ADAPT_STRUCT( demo::employee, (auto, name) (auto, age) )

It also looks kind of similar to C++14 lambdas.

That looks nice, and it may be great, but I'm a bit concerned in giving a slight different meaning than the official one to a standard keyword.

Could you describe the difference?

Actually there is not much difference, but what I wanted to say is that I am concerned, because it is the responsibilities of the compiler to implement the auto keyword, and if I was just forwarding it in the macros it would make sense to me, but I'm replacing it with BOOST_TYPEOF. Which is a decltype on recent compiler but an emulation on older compilier. In fact I'm just unsure if this wouldn't be a mistake by reusing a keyword which is already reserved by the standard and where is well defined usage for it : variable initialization and function return statement. Possibly decltype would make more sense ? Or even typeof ?

Andrey Semashev

9:56 a.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On Tuesday 17 March 2015 10:23:43 Damien Buhl wrote:

...

On 11/03/2015 08:49, Andrey Semashev wrote:

...
On Wed, Mar 11, 2015 at 10:29 AM, Damien Buhl wrote: [...]

...
...
Perhaps, 'auto' would be shorter?

BOOST_FUSION_ADAPT_STRUCT(

demo::employee, (auto, name) (auto, age)

)

It also looks kind of similar to C++14 lambdas.

That looks nice, and it may be great, but I'm a bit concerned in giving a slight different meaning than the official one to a standard keyword.

Could you describe the difference?

Actually there is not much difference, but what I wanted to say is that I am concerned, because it is the responsibilities of the compiler to implement the auto keyword, and if I was just forwarding it in the macros it would make sense to me, but I'm replacing it with BOOST_TYPEOF.

Which is a decltype on recent compiler but an emulation on older compilier.

In fact I'm just unsure if this wouldn't be a mistake by reusing a keyword which is already reserved by the standard and where is well defined usage for it : variable initialization and function return statement.

...and lambda arguments. Well, you're not actually using auto as a language keyword. IIUC the implementation will be the same as the current one, only replacing the long Fusion macro-like token with auto. The appealing point for auto is that as far as I can tell, type deduction rules for the adapted members should be very similar to those of auto. Actually, my suggestion of auto is only partly motivated by semantics similarity. What I also wanted is to have a shorter keyword instead of BOOST_FUSION_ADAPT_AUTO which is way too long IMHO, and which I'll certainly forget. I'm ok if you feel that auto does not suit well, but I would still like a shorter alternative. The problem is that it has to be either sufficiently qualified in order not to clash with user types or macros (in which case we're back to BOOST_FUSION_ADAPT_AUTO) or be a language keyword. I could also suggest the "_" placeholder, which is less informative but short.

...

Possibly decltype would make more sense ? Or even typeof ?

Both these require an argument, which I don't think makes sense in this context. Using these keywords without an argument makes even less sense to me.

Damien Buhl

2:28 p.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On 17/03/2015 10:56, Andrey Semashev wrote:

...

...and lambda arguments.

Thanks for completeness :).

...

Well, you're not actually using auto as a language keyword. IIUC the implementation will be the same as the current one, only replacing the long Fusion macro-like token with auto. The appealing point for auto is that as far as I can tell, type deduction rules for the adapted members should be very similar to those of auto.

Actually, my suggestion of auto is only partly motivated by semantics similarity. What I also wanted is to have a shorter keyword instead of BOOST_FUSION_ADAPT_AUTO which is way too long IMHO, and which I'll certainly forget. I'm ok if you feel that auto does not suit well, but I would still like a shorter alternative. The problem is that it has to be either sufficiently qualified in order not to clash with user types or macros (in which case we're back to BOOST_FUSION_ADAPT_AUTO) or be a language keyword. I could also suggest the "_" placeholder, which is less informative but short.

I agree with you, and I'm trying to reduce to AUTO at least, if I get courageous enough I'll try to put lowercase auto, but currently BOOST_FUSION_ADAPT_AUTO is just a fallback when no BOOST_PP_VARIADICS support is active. I have added this only for support on older preprocessors. Most have BOOST_PP_VARIADICS, and if it's a question of being short or remembering, then you don't need to remember anything else than you can completely omit the type or mix it with type declaration. As such : BOOST_FUSION_ADAPT_STRUCT( demo::employee, (int, name), age, (std::string, location) (int, salary), gender ) But usually one has no reason to repeat the type, it's mainly for backward compatibility and possibly for people using implicit-conversion to some other common type that I added this. So normally today, one would write : BOOST_FUSION_ADAPT_STRUCT( demo::employee, name, age, location, salary, gender )

...

...
Possibly decltype would make more sense ? Or even typeof ?

Both these require an argument, which I don't think makes sense in this context. Using these keywords without an argument makes even less sense to me.

Fletcher, John P

24 Mar 24 Mar

12:09 p.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Damien Buhl Sent: 17 March 2015 14:28 To: boost@lists.boost.org Subject: Re: [boost] MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix On 17/03/2015 10:56, Andrey Semashev wrote:

...

...and lambda arguments.

Thanks for completeness :).

...

Well, you're not actually using auto as a language keyword. IIUC the implementation will be the same as the current one, only replacing the long Fusion macro-like token with auto. The appealing point for auto is that as far as I can tell, type deduction rules for the adapted members should be very similar to those of auto.

Actually, my suggestion of auto is only partly motivated by semantics similarity. What I also wanted is to have a shorter keyword instead of BOOST_FUSION_ADAPT_AUTO which is way too long IMHO, and which I'll certainly forget. I'm ok if you feel that auto does not suit well, but I would still like a shorter alternative. The problem is that it has to be either sufficiently qualified in order not to clash with user types or macros (in which case we're back to BOOST_FUSION_ADAPT_AUTO) or be a language keyword. I could also suggest the "_" placeholder, which is less informative but short.

...

...
Possibly decltype would make more sense ? Or even typeof ?

Both these require an argument, which I don't think makes sense in this context. Using these keywords without an argument makes even less sense to me.

yes it's even worse when I think more after it. I'll send you the link to the pull-request when I'll be done with a proposal in this sense. Thanks to your input I'm getting more confident in using auto as keyword for the fallback. :p. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost My apologies that I missed that these messages are about Phoenix. Is there a change of some sort needed in Phoenix? I am not able to run any versions of MSVC so I cannot check, but will put up tests as needed. John

Andrey Semashev

12:30 p.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On Tue, Mar 24, 2015 at 3:09 PM, Fletcher, John P wrote:

...

My apologies that I missed that these messages are about Phoenix. Is there a change of some sort needed in Phoenix?

I believe, if Damien is not able to remove BOOST_PP_IS_EMPTY use from Fusion, you could try to disable the warnings in Phoenix. The warnings will still be emitted for user's code involving Fusion but at least Phoenix won't worsen the situation.

Damien Buhl

31 Mar 31 Mar

7:20 a.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On 24/03/2015 13:30, Andrey Semashev wrote:

...

On Tue, Mar 24, 2015 at 3:09 PM, Fletcher, John P wrote:

...
My apologies that I missed that these messages are about Phoenix. Is there a change of some sort needed in Phoenix?

I believe, if Damien is not able to remove BOOST_PP_IS_EMPTY use from Fusion, you could try to disable the warnings in Phoenix. The warnings will still be emitted for user's code involving Fusion but at least Phoenix won't worsen the situation.

So I could remove BOOST_PP_IS_EMPTY, and added auto as synonym for BOOST_FUSION_ADAPT_AUTO. This is for the moment in a feature branch on top of Boost.Fusion develop. I need to adapt the documentation regarding the change for auto and thoroughly test on the different compilers before I can pull-request to Joël de Guzman. I have to install MSVC 8 to ensure it doens't make any warnings anymore there. It shouldn't, but we never know. In case I've opened an issue : https://svn.boost.org/trac/boost/ticket/11157 and the changes can be seen on github :

...

https://github.com/daminetreg/fusion/commit/6da2d800398d5197b1bee0609043551c...

I think it should be no problem to have the changes in master for 1.59. Cheers, -- Damien Buhl (alias daminetreg)

Andrey Semashev

8:08 a.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On Tuesday 31 March 2015 09:20:37 Damien Buhl wrote:

...

On 24/03/2015 13:30, Andrey Semashev wrote:

...
On Tue, Mar 24, 2015 at 3:09 PM, Fletcher, John P

wrote:

...
My apologies that I missed that these messages are about Phoenix. Is there a change of some sort needed in Phoenix?> I believe, if Damien is not able to remove BOOST_PP_IS_EMPTY use from Fusion, you could try to disable the warnings in Phoenix. The warnings will still be emitted for user's code involving Fusion but at least Phoenix won't worsen the situation.

So I could remove BOOST_PP_IS_EMPTY, and added auto as synonym for BOOST_FUSION_ADAPT_AUTO.

This is for the moment in a feature branch on top of Boost.Fusion develop.

I need to adapt the documentation regarding the change for auto and thoroughly test on the different compilers before I can pull-request to Joël de Guzman.

I have to install MSVC 8 to ensure it doens't make any warnings anymore there. It shouldn't, but we never know.

In case I've opened an issue : https://svn.boost.org/trac/boost/ticket/11157 and the changes can be

seen on github :

...
https://github.com/daminetreg/fusion/commit/6da2d800398d5197b1bee060904355 1cd839b4ad I think it should be no problem to have the changes in master for 1.59.

Thank you, Damien.

Damien Buhl

9:26 p.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On 31/03/2015 10:08, Andrey Semashev wrote:

...

On Tuesday 31 March 2015 09:20:37 Damien Buhl wrote:

...
On 24/03/2015 13:30, Andrey Semashev wrote: [...]

So I could remove BOOST_PP_IS_EMPTY, and added auto as synonym for BOOST_FUSION_ADAPT_AUTO.

This is for the moment in a feature branch on top of Boost.Fusion develop.

I need to adapt the documentation regarding the change for auto and thoroughly test on the different compilers before I can pull-request to Joël de Guzman.

I have to install MSVC 8 to ensure it doens't make any warnings anymore there. It shouldn't, but we never know.

In case I've opened an issue : https://svn.boost.org/trac/boost/ticket/11157 and the changes can be

seen on github :

...
https://github.com/daminetreg/fusion/commit/6da2d800398d5197b1bee060904355 1cd839b4ad I think it should be no problem to have the changes in master for 1.59.

Thank you, Damien.

Thank you for reporting the issue and discussing the aspect about using lowercase auto. :) I'll tell you as soon as I'll have tested on the different compilers.

Damien Buhl

24 Mar 24 Mar

12:53 p.m.

New subject: MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix

On 24/03/2015 13:09, Fletcher, John P wrote:

...

My apologies that I missed that these messages are about Phoenix. Is there a change of some sort needed in Phoenix?

I am not able to run any versions of MSVC so I cannot check, but will put up tests as needed.

Hi John, I'm in the process of removing BOOST_PP_IS_EMPTY usage from the code, I'm just facing some difficulties as I thought it would be easier to change. But I still think it's doable, so I would say it's better to not change anything and get the next version of Boost.Fusion fix the warnings automatically, than adding any warning disabling pragmas in your code. Before all it's on older version of MSVC, namely MSVC 8. So I think we can temporarily (maximally until next release) live with the warnings. Cheers, -- Damien Buhl

Edward Diener

10 Mar 10 Mar

2:36 p.m.

On 3/10/2015 1:54 AM, Damien Buhl wrote:

...

On 09/03/2015 23:20, Edward Diener wrote:

...
On 3/9/2015 5:09 PM, Andrey Semashev wrote: [...]

...
There weren't any warnings before. Is this a result of a change in Boost.PP?

Yes, but they were already in 1.57. The changes added some new (BOOST_PP_IS_BEGIN_PARENS) and better functionality (the internal BOOST_PP_IS_EMPTY) to Boost PP, as well as fixing some corner cases with VC++ I discovered when testing VMD.

The reason why this happens more in this build, is that the new BOOST_FUSION_ADAPT macros uses BOOST_PP_IS_EMPTY for each field member now. This is used to determine if the type was provided or has to be deduced.

In all the test I ran I got no warning under VC++, but this was on a pretty new version. And some of my test were run before 1.57.

The BOOST_PP_IS_EMPTY macro is undocumented in Boost PP and therefore was not meant to be used outside the library. I actually changed it to be much more reliable when using variadic macros, but unfortunately that mean that VC++ puts out more spurious warning messages. Honestly just getting VC++ to work properly in Boost PP and VMD is hard enough. Fixing VC++ warning messages, when there is nothing wrong, is nearly impossible. I understand they are irritating but they are totally false also. They are part of VC++'s non-conformant C++ preprocessor.

...

...
Turning off C4003 globally for VC++ is the only solution to the VC++ warnings I could ever discover. I attempted to turn off the warnings in the macros where they occur, but VC++ just ignores that. Evidently the warnings can only be turned off globally or possibly at the very top-level macro which eventually causes them.

Do you think I could add specific pragmas to disable C4003 where I use BOOST_PP_IS_EMPTY ?

You can try it by surrounding the top-level macro, which eventually calls BOOST_PP_EMPTY, with the appropriate VC++ pragmas to turn off the warning. But even that may not work with VC++. I tried to use the appropriate VC++ pragmas at the Boost PP level to turn off the warnings but it did not succeed.

3528

Age (days ago)

3614

Last active (days ago)

List overview

Download

55 comments

12 participants

participants (12)

Andrey Semashev
Beman Dawes
Damien Buhl
Edward Diener
Fletcher, John P
Gavin Lambert
Gennadiy Rozental
Jürgen Hunold
Oliver Kowalke
Paul A. Bristow
Peter Dimov
Vladimir Prus