[cfe-dev] Compiling a simple Win32 program

[Jon]

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
>
>
>
>
> --
> -- Love Thy Frog!