I suggest that you don't hardwire the info into the tool but rather make an external text file with a list of places to search or something. Once I get around to it, I was planning to look into eliminating the hardwired paths from Clang because they are only marginally useful on Windows and are very likely to cause all sorts of unexpected behavior - if, for instance, the user has multiple version of Mingw installed (I have both Mingw32 and Mingw64 installed). Luckily, I decided to name my Mingw32 installation that: C:\Mingw32. Otherwise, Clang would have made use of Mingw32 features even though it was built as a 64-bit compiler that should only make use of Mingw64. Perhaps a new option, "-basedir" or something, should be added so the user can explicitly specify what directory to use as the base directory for include file and library searches.<br>
<br><div class="gmail_quote">2012/6/13 Nikola Smiljanic <span dir="ltr"><<a href="mailto:popizdeh@gmail.com" target="_blank">popizdeh@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
MinGW users should be in the clear since GnuWin32 only collides with link.exe from VS, or so I think. The question is how to decide whether to search for msvc or mingw, but this is where the default triple comes into play?<div class="HOEnZb">
<div class="h5"><br>
<br><div class="gmail_quote">On Wed, Jun 13, 2012 at 9:59 AM, Mikael Lyngvig <span dir="ltr"><<a href="mailto:mikael@lyngvig.org" target="_blank">mikael@lyngvig.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hehe, what if the user prepends the GnuWin32 tools or MSYS to the path AFTER having run vcvarsall.bat? Anyway, I figure that most LLVM users are bright enough that they'll figure it out quickly.<div><div>
<br><br><div class="gmail_quote">
2012/6/13 Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, Jun 12, 2012 at 8:09 PM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org" target="_blank">mikael@lyngvig.org</a>> 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. So<br>
> if the user sets up an environment to use GnuWin32 and Mingw32, so as to be<br>
> able to run the llvm test suite, you'll bug into this one.<br>
<br>
</div>vcvars prepends it's paths to PATH, so it will not find gnuwin32 or<br>
mingw/msys link.<br>
<span><font color="#888888"><br>
- Michael Spencer<br>
</font></span><div><div><br>
> 2012/6/12 Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com" target="_blank">popizdeh@gmail.com</a>><br>
>><br>
>> It will search the path to find the first link.exe. The one from 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" target="_blank">kim.grasman@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> That sounds like it would match my expectations for behavior, good idea!<br>
>>><br>
>>> Can you have it fall back on %PATH% if no VS environment variables are<br>
>>> found?<br>
>>><br>
>>> Thanks,<br>
>>> - Kim<br></div></div></blockquote></div>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Love Thy Frog!<br>