[cfe-dev] Compiling a simple Win32 program
Mikael Lyngvig
mikael at lyngvig.org
Wed Jun 13 14:37:41 PDT 2012
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.
<xml blah blah>
<toolchain name="GNU v4.7.1 for Win64">
<include>...</include>
</xml>
Nevermind me, I'm rambling :)
2012/6/13 Jon <jon.forums at gmail.com>
> Spectacular.
>
> Of course, I'm now thinking...hey, who wants a simple line delimited
> hlper file...it's time to tinker with creating a simple DSL (a la
> macports) for the toolchain file (use similar to cmake toolchain
> files) and tie it in with the existing clang toolchain data
> structures. Something like:
>
> // clang toolchain file: my_msys_mingw64_toolchain
> // split on ';' for spacey dir, cross-platform goodness
> prepend_path C:/devkit-4.7.1/bin;C:/devkit-4.7.1/mingw/bin
>
> prepend_include
>
> C:/devkit-4.7.1/mingw/include;C:/devkit-4.7.1/mingw/i686-w64-mingw32/include;...
>
> 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
>
>
> Nikola...if you want to quickly experiment with supporting
> implementations of 32bit msys+mingw/mingw-w64 toolchains, as part of
> another project I've created a build recipe that assembles mingw or
> mingw-w64 artifacts in a `mingw` subdir under msys artifacts. For
> example:
>
>
> https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-68
>
> https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb#L3-36
>
> https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw.rb#L3-45
>
> It's called the DevKit and it's primarily meant to help Ruby on
> Windows users easily build native C extensions. It's also a reasonably
> capable standalone toolchain.
>
> While you could build the DevKit yourself (`rake devkit sfx=1
> dkver=mingw-32-4.6.2`) it's easier to just download a prebuilt version
> from https://github.com/thecodeshop/ruby/wiki/Downloads I've
> currently got 32bit mingw+gcc 4.6.2 and mingw-w64+gcc 4.7.1 versions.
>
> Jon
>
>
> On Wed, Jun 13, 2012 at 1:06 PM, Mikael Lyngvig <mikael at lyngvig.org>
> wrote:
> > I suppose this code holds the answer to your question:
> >
> > [llvm/tools/clang/lib/driver/ToolChains.cpp:1076]
> >
> > StringRef GCCToolchainDir = getGCCToolchainDir(Args);
> > if (GCCToolchainDir != "") {
> > if (GCCToolchainDir.back() == '/')
> > GCCToolchainDir = GCCToolchainDir.drop_back(); // remove the /
> >
> > Prefixes.push_back(GCCToolchainDir);
> > } else {
> > Prefixes.push_back(D.SysRoot);
> > Prefixes.push_back(D.SysRoot + "/usr");
> > Prefixes.push_back(D.InstalledDir + "/..");
> > }
> >
> > As far as I interpret that, it simply adds the directory, if it is
> non-empty
> > that is, to the list of prefixes to search through. So there would be no
> > trouble in simply reading in a list of directories, perhaps from a file
> in
> > the root directory of the toolchain directory, and add those to the list
> of
> > prefixes rather than the -gcc-toolchain value itself. The variable
> > GCCToolchainDir is not used anywhere else but in the code above.
> >
> > 2012/6/13 Jon <jon.forums at gmail.com>
> >>
> >> I've not yet looked, but have either of you investigated whether
> >> `-gcc-toolchain` could be cleanly updated to support a "toolchain
> >> include dirs" file to support custom installs of msys, mingw,
> >> mingw-w64 environments not fitting the standard location assumptions?
> >>
> >> For example: `clang -gcc-toolchain @my_msys-mingw64_dirs_file ...`
> >>
> >> Perhaps it already works this way, but I haven't had time to spelunk.
> >>
> >> Jon
> >>
> >>
> >>
> >> On Wed, Jun 13, 2012 at 4:15 AM, Mikael Lyngvig <mikael at lyngvig.org>
> >> wrote:
> >> > 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.
> >> >
> >> >
> >> > 2012/6/13 Nikola Smiljanic <popizdeh at gmail.com>
> >> >>
> >> >> 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?
> >> >>
> >> >>
> >> >> On Wed, Jun 13, 2012 at 9:59 AM, Mikael Lyngvig <mikael at lyngvig.org>
> >> >> wrote:
> >> >>>
> >> >>> 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.
> >> >>>
> >> >>>
> >> >>> 2012/6/13 Michael Spencer <bigcheesegs at gmail.com>
> >> >>>>
> >> >>>> On Tue, Jun 12, 2012 at 8:09 PM, Mikael Lyngvig <
> mikael at lyngvig.org>
> >> >>>> wrote:
> >> >>>> > Just be aware that GnuWin32 includes a link.exe command, which
> >> >>>> > creates
> >> >>>> > symbolic or hard links (not sure which). It is part of GNU
> >> >>>> > coreutils.
> >> >>>> > So
> >> >>>> > if the user sets up an environment to use GnuWin32 and Mingw32,
> so
> >> >>>> > as
> >> >>>> > to be
> >> >>>> > able to run the llvm test suite, you'll bug into this one.
> >> >>>>
> >> >>>> vcvars prepends it's paths to PATH, so it will not find gnuwin32 or
> >> >>>> mingw/msys link.
> >> >>>>
> >> >>>> - Michael Spencer
> >> >>>>
> >> >>>> > 2012/6/12 Nikola Smiljanic <popizdeh at gmail.com>
> >> >>>> >>
> >> >>>> >> It will search the path to find the first link.exe. The one from
> >> >>>> >> Visual
> >> >>>> >> Studio should be first if Command prompt or vcvars.bat are used.
> >> >>>> >>
> >> >>>> >>
> >> >>>> >> On Tue, Jun 12, 2012 at 2:23 PM, Kim Gräsman
> >> >>>> >> <kim.grasman at gmail.com>
> >> >>>> >> wrote:
> >> >>>> >>>
> >> >>>> >>>
> >> >>>> >>> That sounds like it would match my expectations for behavior,
> >> >>>> >>> good
> >> >>>> >>> idea!
> >> >>>> >>>
> >> >>>> >>> Can you have it fall back on %PATH% if no VS environment
> >> >>>> >>> variables
> >> >>>> >>> are
> >> >>>> >>> found?
> >> >>>> >>>
> >> >>>> >>> Thanks,
> >> >>>> >>> - Kim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120613/25c452ef/attachment.html>
More information about the cfe-dev
mailing list