not split(os.sep). Haven't coded in Pythonf or a few years, but you know what I mean: os.something, the PATH separator.<br><br><div class="gmail_quote">2012/6/14 Mikael Lyngvig <span dir="ltr"><<a href="mailto:mikael@lyngvig.org" target="_blank">mikael@lyngvig.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the "which version" solves itself if you use the algorithm I proposed:<div><br></div><div>paths = os.environ["PATH"].split(os.sep)</div>
<div>for path in paths:</div><div> # todo: clean up path and ignore empty path elements</div>
<div> if os.path.exist(path + "cl.exe"):</div><div> return ( path, MSVC )</div><div> elif os.path.exist(path + "g++.exe"):</div><div> return ( path, GCC )</div><div>throw Error("Unknown toolchain - use -toolchain option to specify root of your toolchain.")</div>
<div><br></div><div>Then the user just needs to be careful in setting up the path, something that we all have to be with Clang, and everything works very sensibly and logically.</div><div><br></div><div>On Windows, the PATH rules. There are as a rule of thumb no hard-coded paths and everybody's supposed to use argv[0] to locate their data files. Obviously, that does not go well with Clang, but that's also part of why I am pushing for a Windows-style all-included binary release of Clang for Windows (something I am working on).</div>
<div><br></div><div>As for the guesswork code, well, I never liked such code. It always ends up biting somebody in a soft spot. Much better is to mandate that the user explicitly specify the fictitious -toolchain or -tooldir option on Windows, even though this is less than perfect. Perhaps we could introduce a sensible environment variable? CLANG_TOOLDIR or so. That's also very Windows-like. And that wouldn't require any configuration files.</div>
<div class="HOEnZb"><div class="h5">
<div><br></div><div><br><div class="gmail_quote">2012/6/14 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 Wed, Jun 13, 2012 at 5:09 AM, Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com" target="_blank">popizdeh@gmail.com</a>> wrote:<br>
> I think there is more than one issue here.<br>
><br>
> These things are still unclear to me:<br>
> 1. If both VS and MinGW are installed, which toolchain should Clang use and<br>
> how to decide?<br>
<br>
</div>I would like to follow the principle of least surprise here. What do<br>
users expect? MSVC has a well established way of picking the toolchain<br>
to use based on bat files but I'm not sure how MinGW users are used to<br>
dealing with multiple versions of the toolchain. There's also no<br>
precedent for a tool that can work with either.<br>
<div><br>
> 2. How to obtain the target triple once we've selected the toolchain? Right<br>
> now Clang selects the toolchain based on the default target triple (comming<br>
> from config.h when Clang is compiled).<br>
<br>
</div>This is similar to the issues above. What does the user expect? Again<br>
MSVC uses bat files, and I have no idea how MinGW handles this.<br>
<br>
I feel that basing this choice on how clang was compiled is the wrong<br>
way to do it, as we currently end up often making the obviously wrong<br>
choice.<br>
<div><br>
> 3. How to decide what the target platform is when using either mingw-w64 or<br>
> multiple mingw installations? For VS, toolchains for different targets are<br>
> in different directories and this is easy to detect, but I don't know how<br>
> this exactly works for MinGW/MinGW-W64. I think they have an executable for<br>
> every target?<br>
<br>
</div>Isn't this exactly the same as choosing the target triple? Also I<br>
assume by platform you only mean x86 vs x86-64.<br>
<div><br>
> Things I do know, at least partially:<br>
> - If multiple versions of VS are installed, Clang will select the first one<br>
> in the PATH.<br>
<br>
</div>It's actually currently a lot more complicated than this. First it<br>
adds %INCLUDE%, then it tries %VCINSTALLDIR%, then it tries the<br>
registry to pick the highest version, then it uses<br>
%VS{80|90|100}COMNTOOLS% depending on the version it was compiled<br>
with, then any of them. And that's just for the VS paths. It then goes<br>
and looks for the Windows SDK in the registry, which is already added<br>
to %INCLUDE% by vcvars.bat. So we actually end up with multiple<br>
versions of MSVC on the path. However the link.exe it picks is always<br>
the first one on the path, which always uses %LIB% to look for<br>
libraries.<br>
<br>
This clearly needs to be cleaned up :P.<br>
<div><br>
> - Same logic should apply for multiple MinGW/MSYS versions. "which gcc"<br>
> should give back the active toolchain. The question about the target still<br>
> remains.<br>
<br>
</div>I agree in part. I do however wonder how we would handle a distro of<br>
MinGW that completely removes gcc in favor of clang.<br>
<div><br>
> - In the case of VS the target is decided based on the toolchain's directory<br>
> (the one in VC\bin targets x86, etc.)<br>
<br>
</div>The target is decided by the binary yes, but the headers and libs are<br>
decided by %INCLUDE% and %LIB%.<br>
<div><br>
> A bit unrelated issue is the one about MinGW toolchain support inside Clang<br>
> codebase, or the lack thereof. This is why the hardcoded paths are still<br>
> needed in InitHeaderSearch. This is something that needs to be done, I had a<br>
> look into it but never found enough time to do something useful. I think<br>
> this is the first thing to work on If you're interested in better MinGW<br>
> support. For more info look<br>
> 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<br>
> reply from Chandler).<br>
<br>
</div>Agreed that this all goes in the driver. But selecting the exact<br>
version to use is a bit more complicated than with gcc on Linux. At<br>
least from what I've seen.<br>
<div><br>
> As for the external text files, I don't think a feature like that could be<br>
> implemented without discussing it first with larger community. Just<br>
> something to take into account if you had any plans to work on something<br>
> like this. This is just my personal impression after following the list for<br>
> some time :)<br>
<br>
</div>There is a strong aversion to text config files for toolchains unless<br>
absolutely necessary.<br>
<span><font color="#888888"><br>
- Michael Spencer<br>
</font></span><div><div><br>
> On Wed, Jun 13, 2012 at 10:15 AM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org" target="_blank">mikael@lyngvig.org</a>> wrote:<br>
>><br>
>> I suggest that you don't hardwire the info into the tool but rather make<br>
>> an external text file with a list of places to search or something. Once I<br>
>> get around to it, I was planning to look into eliminating the hardwired<br>
>> paths from Clang because they are only marginally useful on Windows and are<br>
>> very likely to cause all sorts of unexpected behavior - if, for instance,<br>
>> the 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" target="_blank">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" target="_blank">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" target="_blank">bigcheesegs@gmail.com</a>><br>
>>>>><br>
>>>>> On Tue, Jun 12, 2012 at 8:09 PM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org" target="_blank">mikael@lyngvig.org</a>><br>
>>>>> wrote:<br>
>>>>> > Just be aware that GnuWin32 includes a link.exe command, which<br>
>>>>> > creates<br>
>>>>> > symbolic or hard links (not sure which). It is part of GNU<br>
>>>>> > coreutils. 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" target="_blank">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" target="_blank">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>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> -- Love Thy Frog!<br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Love Thy Frog!<br>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Love Thy Frog!<br>