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

newer
[GSoC '15] Boost Documant Library...

older
[svg] is there any interest in a...

Vladimir Prus

18 Feb 2015 18 Feb '15

3:58 p.m.

On 02/18/2015 05:55 PM, Jürgen Hunold wrote:

...

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.

Well, it my brief check, it was the headers->system path that first requested system with address-model=32. Anyway, it does not matter for the rest of this discussion.

...

...
- 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?

That's roughly what I propose, too - but there are few further tweaks and options.

...

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.

Right, so steps would be: 1. Move actual tests into config (we do need to have a few cpp files) 2. Move architecture.jam into either Boost.Build or boostcpp.jam 3. Make sure we don't generate extra path elements for default address model 4. Introduce a way to do these tests without requiring a bunch of .cpp files - sure Boost.Build can generate them on the fly. 5. Make these checks be automatic for all projects. It seems that 1-2 should solve the immediate problem, and 1-3 should be pretty good, although going all the way to 5 would be cool.

...

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...

Not sure I have an opinion on that. -- Vladimir Prus CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software/

Show replies by date

Jürgen Hunold

18 Feb 18 Feb

4:10 p.m.

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

Am Mittwoch, 18. Februar 2015, 18:58:01 schrieb Vladimir Prus:

...

On 02/18/2015 05:55 PM, Jürgen Hunold wrote:

...
I thought the correct way would be to move the architecture detection upwards?

...

That's roughly what I propose, too - but there are few further tweaks and options.

...

...
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.

Right, so steps would be:

1. Move actual tests into config (we do need to have a few cpp files) 2. Move architecture.jam into either Boost.Build or boostcpp.jam 3. Make sure we don't generate extra path elements for default address model 4. Introduce a way to do these tests without requiring a bunch of .cpp files - sure Boost.Build can generate them on the fly. 5. Make these checks be automatic for all projects.

It seems that 1-2 should solve the immediate problem, and 1-3 should be pretty good, although going all the way to 5 would be cool.

+1 for this plan. And it would be cool if 3 enables me to use "feature.set-default address-model : 64" on Windows 64 bit machines to enforce 64 bit builds as default. Or maybe just auto-detect it...

...

...
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...

Not sure I have an opinion on that.

I just wanted to mention it. I've tried this way but it quickly gets dirty as soon as one gets both "header-only" and library. So -2 for this solution. 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

19 Feb 19 Feb

9:09 a.m.

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

On 02/18/2015 07:10 PM, Jürgen Hunold wrote:

...

...
Right, so steps would be:

...
1. Move actual tests into config (we do need to have a few cpp files) 2. Move architecture.jam into either Boost.Build or boostcpp.jam 3. Make sure we don't generate extra path elements for default address model 4. Introduce a way to do these tests without requiring a bunch of .cpp files - sure Boost.Build can generate them on the fly. 5. Make these checks be automatic for all projects.

It seems that 1-2 should solve the immediate problem, and 1-3 should be pretty good, although going all the way to 5 would be cool.

+1 for this plan.

And it would be cool if 3 enables me to use "feature.set-default address-model : 64" on Windows 64 bit machines to enforce 64 bit builds as default. Or maybe just auto-detect it...

I have patches for 1-2, over at: https://gist.github.com/vprus/6017091aef8126919980 You will need --without-log for them to work. Hiding architecture/address-model from path is not quite as easy, since that must be done per toolchain; different toolchains can have different defaults. Or I can possibly just use "64" and "x86", without feature name, in target paths. - Volodya -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Paul A. Bristow

28 Feb 28 Feb

3:44 p.m.

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

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: 19 February 2015 09:10 To: boost@lists.boost.org Subject: Re: [boost] [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)

On 02/18/2015 07:10 PM, Jürgen Hunold wrote:

...
...
Right, so steps would be:

...
1. Move actual tests into config (we do need to have a few cpp files) 2. Move architecture.jam into either Boost.Build or boostcpp.jam 3. Make sure we don't generate extra path elements for default address model 4. Introduce a way to do these tests without requiring a bunch of .cpp files - sure Boost.Build can generate them on the fly. 5. Make these checks be automatic for all projects.

It seems that 1-2 should solve the immediate problem, and 1-3 should be pretty good, although going all the way to 5 would be cool.

+1 for this plan.

And it would be cool if 3 enables me to use "feature.set-default address-model : 64" on Windows 64 bit machines to enforce 64 bit builds as default. Or maybe just auto-detect it...

I have patches for 1-2, over at:

https://gist.github.com/vprus/6017091aef8126919980

You will need --without-log for them to work.

Hiding architecture/address-model from path is not quite as easy, since that must be done per toolchain; different toolchains can have different defaults. Or I can possibly just use "64" and "x86", without feature name, in target paths.

OK chaps - all this discussion left me in a state of partial disambiguation. But now, after a GIT corruption, I've chosen to start right from the top after deleting my entire module-boost directory, and reinstalling everything from scratch. I'm working on branch develop and trying to build all the libraries, as per https://svn.boost.org/trac/boost/wiki/TryModBoost#InstallingModularBoost . And I'm stuck at this point again. What do I do to get over this for now? Install the patch mentioned https://gist.github.com/vprus/6017091aef8126919980 Try to build with these options? <address-model>32 <architecture>x86 --address-model=32 (actually I'm on Windows 8.1 64-bit, so what should I specify ? --address-model=64 --architecture=ia64 I:\modular-boost>.\b2 --address-model=64 > ../develop-build.log doesn't work :-( I:\modular-boost>.\b2 --address-model=32 > ../develop-build.log doesn't work either :-(( Suggestions please - I'm stuck. Paul PS (supplementary: Will I potentially need both 32 and 64 bit libraries?) Building the Boost C++ Libraries. Performing configuration checks - symlinks supported : yes - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - message-compiler : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : no - long double support : yes 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 incompabile 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. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Steven Watanabe

3:54 p.m.

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

AMDG On 02/28/2015 08:44 AM, Paul A. Bristow wrote:

...

I:\modular-boost>.\b2 --address-model=64 > ../develop-build.log doesn't work :-(

I:\modular-boost>.\b2 --address-model=32 > ../develop-build.log doesn't work either :-((

No "--" It's spelled address-model=32 In Christ, Steven Watanabe

Paul A. Bristow

5:37 p.m.

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

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: 28 February 2015 15:54 To: boost@lists.boost.org Subject: Re: [boost] [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)

AMDG

On 02/28/2015 08:44 AM, Paul A. Bristow wrote:

...
I:\modular-boost>.\b2 --address-model=64 > ../develop-build.log doesn't work :-(

I:\modular-boost>.\b2 --address-model=32 > ../develop-build.log doesn't work either :-((

No "--" It's spelled address-model=32

Indeed - will I ever understand the b2 syntax? :-( It seems, I also need to specify the architecture=ia64 too .\b2 address-model=64 architecture=ia64 > ../develop-build.log 'cl' is not recognized as an internal or external command, operable program or batch file. (I think I haven't chosen the 64 bit compiler version?) .\b2 address-model=32 architecture=x86 > ../develop-build.log is working. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Peter Dimov

5:52 p.m.

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

Paul A. Bristow wrote:

...

It seems, I also need to specify the architecture=ia64 too

.\b2 address-model=64 architecture=ia64 > ../develop-build.log

'ia64' is Itanium. x86-64 is probably address-model=64 architecture=x86. Or not. I haven't tried. :-)

Jürgen Hunold

8 Mar 8 Mar

4:32 p.m.

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

Hi Volodya, the issue popped up on IRC saturday and I decided to take action. We even have a bug report https://svn.boost.org/trac/boost/ticket/10858 for this. Am 19.02.2015 um 10:09 schrieb Vladimir Prus:

...

I have patches for 1-2, over at:

https://gist.github.com/vprus/6017091aef8126919980

I've taken your patches and created a set of pull requests for them. You can start at https://github.com/boostorg/boost/pull/70 and look at the chain from there.

...

You will need --without-log for them to work. Fixed, too. See https://github.com/boostorg/log/pull/5

...

Hiding architecture/address-model from path is not quite as easy, since that must be done per toolchain; different toolchains can have different defaults. Or I can possibly just use "64" and "x86", without feature name, in target paths.

Right. First things first, let us fix the compilation for end-users first. I hope that someone can push all patches as they need to be applied together. 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 -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Oliver Kowalke

4:46 p.m.

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

2015-03-08 17:32 GMT+01:00 Jürgen Hunold : I hope that someone can push all patches as they need to be applied

...

together.

patches for boost.context applied and pushed to branch develop/master

Vladimir Prus

9 Mar 9 Mar

5:26 p.m.

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

On 03/08/2015 09:46 AM, Oliver Kowalke wrote:

...

2015-03-08 17:32 GMT+01:00 Jürgen Hunold :

I hope that someone can push all patches as they need to be applied

...
together.

patches for boost.context applied and pushed to branch develop/master

Thanks. Strictly speaking, I'd expected the change to be pushed only to develop, since master is closed for all changes since 4th, according to calendar. We might be able to roll beta as-is, stay tuned. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Vladimir Prus

11 Mar 11 Mar

6:30 p.m.

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

On 03/09/2015 10:26 AM, Vladimir Prus wrote:

...

On 03/08/2015 09:46 AM, Oliver Kowalke wrote:

...
2015-03-08 17:32 GMT+01:00 Jürgen Hunold :

I hope that someone can push all patches as they need to be applied

...
together.

patches for boost.context applied and pushed to branch develop/master

Thanks.

Strictly speaking, I'd expected the change to be pushed only to develop, since master is closed for all changes since 4th, according to calendar.

We might be able to roll beta as-is, stay tuned.

The release managers have decided that it's better to revert this patch, which I did. I'll put it back after the beta is out. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

John Maddock

8 Mar 8 Mar

5:38 p.m.

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

...

I hope that someone can push all patches as they need to be applied together.

Config is applied. John.

Vladimir Prus

5:44 p.m.

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

On 03/08/2015 09:32 AM, Jürgen Hunold wrote:

...

Hi Volodya,

the issue popped up on IRC saturday and I decided to take action. We even have a bug report https://svn.boost.org/trac/boost/ticket/10858 for this.

Am 19.02.2015 um 10:09 schrieb Vladimir Prus:

...
I have patches for 1-2, over at:

https://gist.github.com/vprus/6017091aef8126919980

I've taken your patches and created a set of pull requests for them. You can start at

https://github.com/boostorg/boost/pull/70

and look at the chain from there.

...
You will need --without-log for them to work. Fixed, too. See https://github.com/boostorg/log/pull/5

...
Hiding architecture/address-model from path is not quite as easy, since that must be done per toolchain; different toolchains can have different defaults. Or I can possibly just use "64" and "x86", without feature name, in target paths.

Right. First things first, let us fix the compilation for end-users first.

I hope that someone can push all patches as they need to be applied together.

Jürgen, thanks for fixing Boost.Log - as soon as that one is in I can push the superproject patch. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Jürgen Hunold

8:03 p.m.

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

Hi Volodya, Am 08.03.2015 um 18:44 schrieb Vladimir Prus:

...

thanks for fixing Boost.Log - as soon as that one is in I can push the superproject patch.

Boost.Log is currently broken due to the already finished move of the detection code from Context to Config. This means you can push the superproject 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

3532

Age (days ago)

3553

Last active (days ago)

List overview

Download

13 comments

7 participants

participants (7)

John Maddock
Jürgen Hunold
Oliver Kowalke
Paul A. Bristow
Peter Dimov
Steven Watanabe
Vladimir Prus