From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2008-03-23 10:27:41
Vladimir Prus wrote:
> I don't think so. One should be able to invoke g++ with an absolute path,
> and then expect that g++ finds everything he wants to find. It's not just
> 'as' binary -- it's also various gcc-version specific libraries (not in PATH
> anyway). I suspect that either you've ended up with partial install, or
> mingw 4.2.1 is buggy.
Hmm, depends on what you mean by "partial install".
I am installing for compilation from CMD.EXE, no MSYS or the like.
But I am trying to argue on a more general basis.
A build system (that promises to being able to do multi compiler) must
be able to control the environment too. Think about when a toolset can
find its subtools only by looking into PATH. And then think about
name clashes of sub-tools that really need to be different for each
main tool invocation.
Following your argumentation requires that all versions of gcc can be
installed in the same tree. And this indeed is possible. So why bother:
I found myself picking up the 'as' from cygwin instead of the mingw one.
And this indeed bothers me.
What shall I do: omit putting cygwin in my PATH? Hmm, then I won't be
able to pick up tools from there that are not in mingw. So-> NoOpt.
Ok, I can put mingw before cygwin in the PATH. But then, how can I
invoke tools from cygwin/bin?
I already mentioned the MSVC case. The toolset implementation
does this setup of environment. And this proves that it is possible
to do. Its just the implementation of gcc.jam does not.
-- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz_at_[hidden] ________| http://www.blackspace.at
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk