Not me, I haven't. Didn't even know about -gcc-toolchain until you mentioned it. I am looking at the clang driver source right now, but somehow I doubt I'll figure out where all this leads before Nikola has an answer ready. (This is my first real dip within the Clang sources.)<div>
<br><div class="gmail_quote">2012/6/13 Jon wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've not yet looked, but have either of you investigated whether<br>
`-gcc-toolchain` could be cleanly updated to support a "toolchain<br>
include dirs" file to support custom installs of msys, mingw,<br>
mingw-w64 environments not fitting the standard location assumptions?<br>
<br>
For example: `clang -gcc-toolchain @my_msys-mingw64_dirs_file ...`<br>
<br>
Perhaps it already works this way, but I haven't had time to spelunk.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Wed, Jun 13, 2012 at 4:15 AM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org">mikael@lyngvig.org</a>> wrote:<br>
> I suggest that you don't hardwire the info into the tool but rather make an<br>
> external text file with a list of places to search or something. Once I get<br>
> around to it, I was planning to look into eliminating the hardwired paths<br>
> from Clang because they are only marginally useful on Windows and are very<br>
> likely to cause all sorts of unexpected behavior - if, for instance, the<br>
> user has multiple version of Mingw installed (I have both Mingw32 and<br>
> Mingw64 installed). Luckily, I decided to name my Mingw32 installation<br>
> that: C:\Mingw32. Otherwise, Clang would have made use of Mingw32 features<br>
> even though it was built as a 64-bit compiler that should only make use of<br>
> Mingw64. Perhaps a new option, "-basedir" or something, should be added so<br>
> the user can explicitly specify what directory to use as the base directory<br>
> for include file and library searches.<br>
><br>
><br>
> 2012/6/13 Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com">popizdeh@gmail.com</a>><br>
>><br>
>> MinGW users should be in the clear since GnuWin32 only collides with<br>
>> link.exe from VS, or so I think. The question is how to decide whether to<br>
>> search for msvc or mingw, but this is where the default triple comes into<br>
>> play?<br>
>><br>
>><br>
>> On Wed, Jun 13, 2012 at 9:59 AM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org">mikael@lyngvig.org</a>><br>
>> wrote:<br>
>>><br>
>>> Hehe, what if the user prepends the GnuWin32 tools or MSYS to the path<br>
>>> AFTER having run vcvarsall.bat? Anyway, I figure that most LLVM users are<br>
>>> bright enough that they'll figure it out quickly.<br>
>>><br>
>>><br>
>>> 2012/6/13 Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>><br>
>>>><br>
>>>> On Tue, Jun 12, 2012 at 8:09 PM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org">mikael@lyngvig.org</a>><br>
>>>> wrote:<br>
>>>> > Just be aware that GnuWin32 includes a link.exe command, which creates<br>
>>>> > symbolic or hard links (not sure which). It is part of GNU coreutils.<br>
>>>> > So<br>
>>>> > if the user sets up an environment to use GnuWin32 and Mingw32, so as<br>
>>>> > to be<br>
>>>> > able to run the llvm test suite, you'll bug into this one.<br>
>>>><br>
>>>> vcvars prepends it's paths to PATH, so it will not find gnuwin32 or<br>
>>>> mingw/msys link.<br>
>>>><br>
>>>> - Michael Spencer<br>
>>>><br>
>>>> > 2012/6/12 Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com">popizdeh@gmail.com</a>><br>
>>>> >><br>
>>>> >> It will search the path to find the first link.exe. The one from<br>
>>>> >> Visual<br>
>>>> >> Studio should be first if Command prompt or vcvars.bat are used.<br>
>>>> >><br>
>>>> >><br>
>>>> >> On Tue, Jun 12, 2012 at 2:23 PM, Kim Gräsman <<a href="mailto:kim.grasman@gmail.com">kim.grasman@gmail.com</a>><br>
>>>> >> wrote:<br>
>>>> >>><br>
>>>> >>><br>
>>>> >>> That sounds like it would match my expectations for behavior, good<br>
>>>> >>> idea!<br>
>>>> >>><br>
>>>> >>> Can you have it fall back on %PATH% if no VS environment variables<br>
>>>> >>> are<br>
>>>> >>> found?<br>
>>>> >>><br>
>>>> >>> Thanks,<br>
>>>> >>> - Kim<br>
</div></div></blockquote></div><br>
</div>