Re: [boost] Compiling with Clang 3.7.0 from windows

Subject: Re: [boost] Compiling with Clang 3.7.0 from windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-09-08 21:26:37

On 9/8/2015 7:56 PM, Gavin Lambert wrote:
> On 9/09/2015 05:38, Edward Diener wrote:
>> I already had a long, frustrating discussion with the mingw-64
>> developers about this and they are just adamant about the necessity that
>> any given implementation's 'bin' directory must be in the PATH to just
>> compile and/or link.
>
> IIRC, their argument was that since the bin directory must be in the
> PATH to run the application (which is wrong, and bad practice for
> non-console apps at least) then they require it to be present when
> compiling so that running the app after compiling "just works".

'Compile/link' and 'run' are two separate steps. Doing the first does 
not always mean doing the second. A number of Boost tests are just 
compiles. An end-user should be allowed to configure a 'run' as he 
desires. Creating pre-conceived assumptions about how software should be 
used which limit the freedom and flexibility of programming is almost 
always a sign of bad programming design.

>
> OTOH, enforcing that does make life easier for people who just want to
> compile and run unixy source packages rather than writing "real" Windows
> apps.

Whether you write a console app or a GUI app DLLs come into play if you 
are doing shared linking. But dictating how these DLLs should be 
accessed at run-time, which is that the mingw-64/gcc developers have 
"decided" to do, is wrong as a default. I am never against optional ways 
to make things easier for programmers as long as flexibility is not 
sacrificed. In this case forcing an implementation's 'bin' directory in 
the PATH is just poor, inflexible, and should not have been done.

But I also don't think Boost build should be doing anything with 
toolsets that are not being used at the b2 invocation level, unless you 
can show me that there is a functional reason for doing so. If I am 
using toolset msvc-14.0 why would Boost build ever need to functionally 
invoke toolset gcc-5.1 ? I do understand that Boost build processing may 
say that when it encounters a 'using xxx' statement it takes some action 
which means that it invokes the toolset, but clearly such information 
could be cached away and only invoked when the particular toolset is 
specified in a b2 command line or used by default in a b2 command line.