My views, even though I'm no guru on LLVM and Clang :-)<div><br></div><div>1. If both VS and MinGW are installed, the first one in the path should take precedence. I almost always have both installed, but I only rarely use Visual Studio as I dislike GUI IDEs and because I am nowadays working on a compiler which uses LLVM (and the VS support on Windows is still not mature enough to be usable with anything but trivial C++ programs, if any at all). So, I'd suggest searching the path from start to end and check each directory for either "g++.exe" or "cl.exe". The one that comes first wins.</div>
<div>2. I don't know. In my mind, hardcoded configuration values are always going to be a big problem for somebody some day, no matter how many likes them. How about doing something like this:</div><div><br></div><div>
let vendor be first compiler in path</div><div>if clang-is-32-bit:</div><div> target = win32</div><div>else:</div><div> target = win64</div><div><br></div><div>That should give you two of the three of the triplet. I think the third is always "pc" on IBM PCs and compatible machines, so that one should be sensible to hardcode (despite what I said above :). Ohh, I don't even know what the triplets normally are on PC. Only rarely saw them on Windows.</div>
<div><br></div><div>I think it is better that you use the build time word size to select target than it is to analyze the path of the VS executables. I, for one, sometimes copy the VS command-line tools elsewhere or even go as far as to use the Windows SDK (it also includes cl.exe and link.exe and so forth).</div>
<div><br></div><div>Right now, I think pretty much everybody are targeting 32-bit Windows, but I have a buildbot slave that builds and tests the 64-bit MingGW version every night. So eventually, it will become the mainstream Windows Clang.</div>
<div><br></div><div>The external text file is only an idea for want of better. I don't like it much myself, but I prefer it to hardcoded paths. We're so fortunate that both MinGW/GCC and Visual Studio use the same basic layout: $DIR/lib and $DIR/include, although I guess you have to know if you're targeting x64 for Visual Studio (you need to add "amd64/" to the path when doing 64-bit links using the Microsoft libraries).</div>
<div><br></div><div>Those are just my two cents and remember that I am no guru on LLVM/Clang, so there's probably many others who have much better ideas :)</div><div><br></div><div>Thanks for the link to the article - I can't seem to find a reply from Chandler in that thread, though.</div>
<div><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">
I think there is more than one issue here.<div><br></div><div>These things are still unclear to me:</div><div>1. If both VS and MinGW are installed, which toolchain should Clang use and how to decide?</div><div>2. How to obtain the target triple once we've selected the toolchain? Right now Clang selects the toolchain based on the default target triple (comming from config.h when Clang is compiled).</div>
<div>3. How to decide what the target platform is when using either mingw-w64 or multiple mingw installations? For VS, toolchains for different targets are in different directories and this is easy to detect, but I don't know how this exactly works for MinGW/MinGW-W64. I think they have an executable for every target?</div>
<div><br></div><div>Things I do know, at least partially:</div><div>- If multiple versions of VS are installed, Clang will select the first one in the PATH.</div><div>- Same logic should apply for multiple MinGW/MSYS versions. "which gcc" should give back the active toolchain. The question about the target still remains.</div>
<div>- In the case of VS the target is decided based on the toolchain's directory (the one in VC\bin targets x86, etc.)
</div><div><br></div><div>A bit unrelated issue is the one about MinGW toolchain support inside Clang codebase, or the lack thereof. This is why the hardcoded paths are still needed in InitHeaderSearch. This is something that needs to be done, I had a look into it but never found enough time to do something useful. I think this is the first thing to work on If you're interested in better MinGW support. For more info look here <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-March/020235.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-March/020235.html</a> (see reply from Chandler).</div>
<div><br></div><div>As for the external text files, I don't think a feature like that could be implemented without discussing it first with larger community. Just something to take into account if you had any plans to work on something like this. This is just my personal impression after following the list for some time :)</div>
<div class="HOEnZb"><div class="h5">
<div><br><div class="gmail_quote">On Wed, Jun 13, 2012 at 10:15 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">
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.<div>
<div><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>
<div><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</div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></div></div></blockquote></div>
</div>