Re: [Boost-build] Problem with mingw flavour

Subject: Re: [Boost-build] Problem with mingw flavour
From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-11-03 17:11:05

On Mon, Nov 3, 2008 at 1:24 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
> On Monday 03 November 2008 23:33:00 Mat Marcus wrote:
>> On Mon, Nov 3, 2008 at 12:06 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
>>    > Assuming I'm on Windows, should
>>
>>     >        bjam target-os=linux
>>
>>     > work (setting architecture to arm), or fail? I don't really
>>     > know,
>>     > but probably we should not be very smart, and fail.
>>
>> I would like to mention a possibly related use case that's important
>> in my environment. I do much of my work from a cygwin bash shell on
>> windows. My clients tend to use cmd.exe, so I also test in that shell.
>> For both shells I generally use a bjam.exe built with msvc. I commonly
>> use an msvc 8 and an msvc 9 toolset, as well as some hand-built
>> (non-mingw) gcc toolsets. My user-config.jam looks includes these
>> lines (and some others):
>>
>> using msvc : 9.0 : "C:/Program Files/Microsoft Visual Studio
>> 9.0/VC/bin/cl.exe" ;
>> using msvc : 8.0 : "C:/Program Files/Microsoft Visual Studio 8/VC/bin/cl.exe" ;
>> using gcc : 4.3.0 : /opt/gcc-4.3.0/bin/g++.exe ;
>>
>> I have some degree of success sharing with this single
>> user-config.jam, regardless of whether I am building from the bash
>> shell or cmd.exe. I've even used a cygwin-built bjam tool under this
>> configuration, IIRC.
>>
>> The main problem that I experience has to do with assumptions made
>> regarding mingw and threading. Since boost 1.35.0 or so, I've needed
>> to add these lines to my user-config.jam:
>>
>>
>> toolset.add-requirements
>>   <toolset>msvc:<target-os>windows
>>   <toolset>msvc:<threadapi>win32 ;
>>
>> toolset.add-requirements
>>   <toolset>gcc:<target-os>cygwin
>>   <toolset>gcc:<threadapi>pthread ;
>>
>> This allows the thread library to build properly regardless of "host
>> shell" or how bjam was compiled. However, this has the side effect of
>> using different paths for build artifacts according to which shell is
>> being used to build. This doubles the space and time required to
>> maintain boost and my libraries, even though the same artifacts are
>> being generated.
>
> Can you explain which artifacts are the same, but generated to different
> directories? Surely, msvc and gcc binaries are not the same, so you
> must mean something else -- can you clarify what?

Sure, sorry that I rambled a bit. Here is what I am referring to. For
each build below I am using the user-config.jam described above and
the cygwin bash shell under windows XP and my (non-mingw) gcc-4.3.0
toolset. When I build from the msvc-built bjam, that is:

/asl/staff/mmarcus/sandbox/boost_libraries/tools/jam/src/bin.ntx86/bjam.exe
gcc-4.3.0

a particular executable ends up at the following path:

C:/adobe_root/built_artifacts/test/property_model_eval/pmeval.test/gcc-4.3.0/debug/architecture-x86/asl-dev\instruction-set-i486/link-static/target-os-cygwin/threadapi-pthread/threading-multi/pmeval.exe

When I build from from the bash shell using a cygwin-built bjam,

/asl/staff/mmarcus/sandbox/boost_libraries/tools/jam/src/bin.cygwinx86/bjam.exe
gcc-4.3.0

the same executable ends up at:

C:/adobe_root/built_artifacts/test/property_model_eval/pmeval.test/gcc-4.3.0/debug/architecture-x86/asl-dev/instruction-set-i486/link-static/threading-multi/pmeval.exe

Yet these paths should contain exactly the same artifacts. I'd like to
be get the same result no matter which shell I use (this works now),
and no matter how bjam was built (this doesn't work now). Bonus: I'd
like to be able to remove the workarounds from the user-config.jam
file.

I understand that this is not exactly a mainstream use case.

 - Mat