Peter Dimov
Peter Dimov
Was that the feature where `address-model=32,64` would silently succeed and build everything twice for e.g. s390x that doesn't have 32 bit?
Is this approach going to work for cross compilation scenarios?
I suppose that if you put the `--target` option in `user-config` it will be properly reflected by `-dumpmachine`, yes.
I think that this is why I made `--with-headers` work, so that one can two-phase install as in ``` b2 -d0 --with-headers install b2 install ```
> So, not sure why you bring `boostcpp.jam` into it. It's because the current logic for deducing the architecture and the address model is in `boostcpp.jam`, as already linked: https://github.com/boostorg/boost/blob/23d255a3b2eec6cc2cd74fb716dc5a41d871bf01/Jamroot#L172-L175....
> Setting a default value for `address-model` will simply ban multiple already in work usages. I don't see why. As an aside, all of my encounters with optional features have...
> Using the host's value seems like a reasonable default. It's not. Consider `b2 toolset=X,Y` where X is 32 bit and Y is 64 bit. > So the build system...
> I feel you pain, I had the same feeling, but honestly, these usages are usually workarounds. About your example: how about fixing undefined behaviors so there is no need...
> You dynamically cast an object (or catching an exception) and the class has hidden visibility? That's a bug in your code :-) No.
There's no user-config in my example. X and Y are built-in toolsets.