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.