I'm going nowhere :) I am just musing at the possibilities. I don't know LLVM or Clang well enough to suggest anything sensible. But would it make sense to use an existing configuration file format and then ask the user to manually configure his or her compiler by putting a file, say "clang.cfg", in the root of his or her compiler directory? Perhaps I should just keep my mouth closed and let you guys figure out what you want to do :-)<br>
<br><div class="gmail_quote">2012/6/13 Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@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="gmail_quote"><div class="im">On Wed, Jun 13, 2012 at 5:37 PM, 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 agree that a simple list of directories is not sufficient so I support your idea. I was myself thinking something along a Python-style configuration file, but then abandoned that train of thought because it would most likely conflict with the rest of LLVM and Clang. How about an XML configuration file? Does that sound stupid or is there in LLVM/Clang are slow transition towards XML? I personally loathe XML, but the alternatives are non-existent, so it might be a sensible choice.<div>
<br></div><div><xml blah blah></div><div><toolchain name="GNU v4.7.1 for Win64"></div><div> <include>...</include></div><div></xml><br></div></blockquote><div><br></div></div><div>
If you're going down that route, there is already infrastructure in LLVM for YAML.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div><div><br></div><div>Nevermind me, I'm rambling :)</div><div><div>
<div><br></div><div><div class="gmail_quote">2012/6/13 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">
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>
C:/devkit-4.7.1/mingw/include;C:/devkit-4.7.1/mingw/i686-w64-mingw32/include;...<br>
<br>
prepend_lib 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>
<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>
<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>
<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>
<span><font color="#888888"><br>
Jon<br>
</font></span><div><div><br>
<br>
On Wed, Jun 13, 2012 at 1:06 PM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org" target="_blank">mikael@lyngvig.org</a>> 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 non-empty<br>
> that is, to the list of prefixes to search through. So there would be no<br>
> trouble in simply reading in a list of directories, perhaps from a file in<br>
> the root directory of the toolchain directory, and add those to the 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" target="_blank">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" target="_blank">mikael@lyngvig.org</a>><br>
>> wrote:<br>
>> > I suggest that you don't hardwire the info into the tool but rather make<br>
>> > an<br>
>> > external text file with a list of places to search or something. 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 are<br>
>> > 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<br>
>> > features<br>
>> > even though it was built as a 64-bit compiler that should only make use<br>
>> > of<br>
>> > Mingw64. Perhaps a new option, "-basedir" or something, should be 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" 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<br>
>> >> to<br>
>> >> search for msvc or mingw, but this is where the default triple comes<br>
>> >> 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<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" 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.<br>
>> >>>> > So<br>
>> >>>> > if the user sets up an environment to use GnuWin32 and Mingw32, 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 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<br>
>> >>>> >> <<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,<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></div></div></blockquote></div>
</div></div></div></div>
<br></div></div><div class="im">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">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></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Love Thy Frog!<br>