Michael Spencer said this earlier:<div><br></div><div><span style> There is a strong aversion to text config files for toolchains unless </span><span style>absolutely necessary.</span> </div><div><br></div><div>So I think it is better to look for a path that involves one or more environment variables (Microsoft's tools use PATH for binaries, LIB for libraries, and INCLUDE for headers). Or, as I suggested, simply mandate that the fictitous -toolchain option be specifed when using Clang-piggybacks-MinGW on Windows. All these problems will go away in the unofficial Clangwin distro that I am working on: There will only be Clang and the correponding MinGW headers and libraries. MinGW is public domain so no problems in doing that. I don't understand at all, why we keep munging about with the piggyback approach on Windows. It makes sense on Unix, yes, but not on Windows. On Windows a translator is supposed to include everything that it needs: the translater, its tools, a runtime library, and the necessary interface files.<br>
<br><div class="gmail_quote">2012/6/14 Jon <span dir="ltr"><<a href="mailto:jon.forums@gmail.com" target="_blank">jon.forums@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Jun 13, 2012 at 5:40 PM, Justin Holewinski<br>
<<a href="mailto:justin.holewinski@gmail.com">justin.holewinski@gmail.com</a>> wrote:<br>
> On Wed, Jun 13, 2012 at 5:37 PM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org">mikael@lyngvig.org</a>> wrote:<br>
>><br>
>> I agree that a simple list of directories is not sufficient so I support<br>
>> your idea. I was myself thinking something along a Python-style<br>
>> configuration file, but then abandoned that train of thought because it<br>
>> would most likely conflict with the rest of LLVM and Clang. How about an<br>
>> XML configuration file? Does that sound stupid or is there in LLVM/Clang<br>
>> are slow transition towards XML? I personally loathe XML, but the<br>
>> alternatives are non-existent, so it might be a sensible choice.<br>
>><br>
>> <xml blah blah><br>
>> <toolchain name="GNU v4.7.1 for Win64"><br>
>> <include>...</include><br>
>> </xml><br>
><br>
> If you're going down that route, there is already infrastructure in LLVM for<br>
> YAML.<br>
<br>
<br>
</div>No kidding, that's great. By chance is it based upon<br>
<a href="http://pyyaml.org/wiki/LibYAML" target="_blank">http://pyyaml.org/wiki/LibYAML</a><br>
<br>
Oh hell, time to get smart on the internals and find time to work up a<br>
prototype for review.<br>
<br>
To be clear, I currently view this YAML toolchain file idea as a<br>
complexity reducer for whatever, if anything, gets baked into the core<br>
code. Rather than the core code becoming overly complex by *trying* to<br>
deal with custom msys/mingw/mingw-w64 installs, support<br>
"non-canonical" msys/mingw installs (define one from clang's pov and<br>
move on) by allowing `-gcc-toolchain` to prepend the info onto<br>
existing clang data structures.<br>
<br>
The toolchain file isn't yet another required config file, rather,<br>
it's an optional way to provide *controlled* buildtime overrides. Very<br>
similar to how one uses cmake toolchain files for cross-compiling.<br>
<br>
This toolchain file idea appears primarily useful for msys/mingw-based<br>
toolchains given the standardized structure of MSVC.<br>
<br>
Before this little siren song gets too tempting, I'd like to hear from<br>
some of the core clang decision makers as to whether the idea looks<br>
promising enough to invest more time into. If the idea has legs, but<br>
needs refinements before it could be accepted, what are the specific<br>
refinements? (assume someone(s) will work up an actual prototype if<br>
interested enough)<br>
<span class="HOEnZb"><font color="#888888"><br>
Jon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
>><br>
>> Nevermind me, I'm rambling :)<br>
>><br>
>> 2012/6/13 Jon <<a href="mailto:jon.forums@gmail.com">jon.forums@gmail.com</a>><br>
>>><br>
>>> Spectacular.<br>
>>><br>
>>> Of course, I'm now thinking...hey, who wants a simple line delimited<br>
>>> hlper file...it's time to tinker with creating a simple DSL (a la<br>
>>> macports) for the toolchain file (use similar to cmake toolchain<br>
>>> files) and tie it in with the existing clang toolchain data<br>
>>> structures. Something like:<br>
>>><br>
>>> // clang toolchain file: my_msys_mingw64_toolchain<br>
>>> // split on ';' for spacey dir, cross-platform goodness<br>
>>> prepend_path C:/devkit-4.7.1/bin;C:/devkit-4.7.1/mingw/bin<br>
>>><br>
>>> prepend_include<br>
>>><br>
>>> C:/devkit-4.7.1/mingw/include;C:/devkit-4.7.1/mingw/i686-w64-mingw32/include;...<br>
>>><br>
>>> prepend_lib<br>
>>> C:/devkit-4.7.1/mingw/i686-w64-mingw32/lib;C:/devkit-4.7.1/mingw/lib/gcc/i686-w64-mingw32/4.7.1<br>
>>><br>
>>><br>
>>> Nikola...if you want to quickly experiment with supporting<br>
>>> implementations of 32bit msys+mingw/mingw-w64 toolchains, as part of<br>
>>> another project I've created a build recipe that assembles mingw or<br>
>>> mingw-w64 artifacts in a `mingw` subdir under msys artifacts. For<br>
>>> example:<br>
>>><br>
>>><br>
>>> <a href="https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-68" target="_blank">https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-68</a><br>
>>><br>
>>> <a href="https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb#L3-36" target="_blank">https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb#L3-36</a><br>
>>><br>
>>> <a href="https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw.rb#L3-45" target="_blank">https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw.rb#L3-45</a><br>
>>><br>
>>> It's called the DevKit and it's primarily meant to help Ruby on<br>
>>> Windows users easily build native C extensions. It's also a reasonably<br>
>>> capable standalone toolchain.<br>
>>><br>
>>> While you could build the DevKit yourself (`rake devkit sfx=1<br>
>>> dkver=mingw-32-4.6.2`) it's easier to just download a prebuilt version<br>
>>> from <a href="https://github.com/thecodeshop/ruby/wiki/Downloads" target="_blank">https://github.com/thecodeshop/ruby/wiki/Downloads</a> I've<br>
>>> currently got 32bit mingw+gcc 4.6.2 and mingw-w64+gcc 4.7.1 versions.<br>
>>><br>
>>> Jon<br>
>>><br>
>>><br>
>>> On Wed, Jun 13, 2012 at 1:06 PM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org">mikael@lyngvig.org</a>><br>
>>> wrote:<br>
>>> > I suppose this code holds the answer to your question:<br>
>>> ><br>
>>> > [llvm/tools/clang/lib/driver/ToolChains.cpp:1076]<br>
>>> ><br>
>>> > StringRef GCCToolchainDir = getGCCToolchainDir(Args);<br>
>>> > if (GCCToolchainDir != "") {<br>
>>> > if (GCCToolchainDir.back() == '/')<br>
>>> > GCCToolchainDir = GCCToolchainDir.drop_back(); // remove the /<br>
>>> ><br>
>>> > Prefixes.push_back(GCCToolchainDir);<br>
>>> > } else {<br>
>>> > Prefixes.push_back(D.SysRoot);<br>
>>> > Prefixes.push_back(D.SysRoot + "/usr");<br>
>>> > Prefixes.push_back(D.InstalledDir + "/..");<br>
>>> > }<br>
>>> ><br>
>>> > As far as I interpret that, it simply adds the directory, if it is<br>
>>> > non-empty<br>
>>> > that is, to the list of prefixes to search through. So there would be<br>
>>> > no<br>
>>> > trouble in simply reading in a list of directories, perhaps from a file<br>
>>> > in<br>
>>> > the root directory of the toolchain directory, and add those to the<br>
>>> > list of<br>
>>> > prefixes rather than the -gcc-toolchain value itself. The variable<br>
>>> > GCCToolchainDir is not used anywhere else but in the code above.<br>
>>> ><br>
>>> > 2012/6/13 Jon <<a href="mailto:jon.forums@gmail.com">jon.forums@gmail.com</a>><br>
>>> >><br>
>>> >> 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>
>>> >><br>
>>> >> Jon<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> On Wed, Jun 13, 2012 at 4:15 AM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org">mikael@lyngvig.org</a>><br>
>>> >> wrote:<br>
>>> >> > I suggest that you don't hardwire the info into the tool but rather<br>
>>> >> > make<br>
>>> >> > an<br>
>>> >> > external text file with a list of places to search or something.<br>
>>> >> > Once I<br>
>>> >> > get<br>
>>> >> > around to it, I was planning to look into eliminating the hardwired<br>
>>> >> > paths<br>
>>> >> > from Clang because they are only marginally useful on Windows and<br>
>>> >> > are<br>
>>> >> > very<br>
>>> >> > likely to cause all sorts of unexpected behavior - if, for instance,<br>
>>> >> > the<br>
>>> >> > user has multiple version of Mingw installed (I have both Mingw32<br>
>>> >> > and<br>
>>> >> > Mingw64 installed). Luckily, I decided to name my Mingw32<br>
>>> >> > installation<br>
>>> >> > that: C:\Mingw32. Otherwise, Clang would have made use of Mingw32<br>
>>> >> > features<br>
>>> >> > even though it was built as a 64-bit compiler that should only make<br>
>>> >> > use<br>
>>> >> > of<br>
>>> >> > Mingw64. Perhaps a new option, "-basedir" or something, should be<br>
>>> >> > added<br>
>>> >> > so<br>
>>> >> > the user can explicitly specify what directory to use as the base<br>
>>> >> > 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<br>
>>> >> >> with<br>
>>> >> >> link.exe from VS, or so I think. The question is how to decide<br>
>>> >> >> whether<br>
>>> >> >> to<br>
>>> >> >> search for msvc or mingw, but this is where the default triple<br>
>>> >> >> comes<br>
>>> >> >> into<br>
>>> >> >> play?<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> On Wed, Jun 13, 2012 at 9:59 AM, Mikael Lyngvig<br>
>>> >> >> <<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<br>
>>> >> >>> path<br>
>>> >> >>> AFTER having run vcvarsall.bat? Anyway, I figure that most LLVM<br>
>>> >> >>> users<br>
>>> >> >>> 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<br>
>>> >> >>>> <<a href="mailto:mikael@lyngvig.org">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.<br>
>>> >> >>>> > So<br>
>>> >> >>>> > if the user sets up an environment to use GnuWin32 and Mingw32,<br>
>>> >> >>>> > so<br>
>>> >> >>>> > 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<br>
>>> >> >>>> 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<br>
>>> >> >>>> >> from<br>
>>> >> >>>> >> Visual<br>
>>> >> >>>> >> Studio should be first if Command prompt or vcvars.bat are<br>
>>> >> >>>> >> used.<br>
>>> >> >>>> >><br>
>>> >> >>>> >><br>
>>> >> >>>> >> On Tue, Jun 12, 2012 at 2:23 PM, Kim Gräsman<br>
>>> >> >>>> >> <<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,<br>
>>> >> >>>> >>> good<br>
>>> >> >>>> >>> idea!<br>
>>> >> >>>> >>><br>
>>> >> >>>> >>> Can you have it fall back on %PATH% if no VS environment<br>
>>> >> >>>> >>> variables<br>
>>> >> >>>> >>> are<br>
>>> >> >>>> >>> found?<br>
>>> >> >>>> >>><br>
>>> >> >>>> >>> Thanks,<br>
>>> >> >>>> >>> - Kim<br>
>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
><br>
> Thanks,<br>
><br>
> Justin Holewinski<br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Love Thy Frog!<br>
</div>