[cfe-dev] Compiling a simple Win32 program
Justin Holewinski
justin.holewinski at gmail.com
Wed Jun 13 14:40:35 PDT 2012
On Wed, Jun 13, 2012 at 5:37 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote:
> 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>
>
If you're going down that route, there is already infrastructure in LLVM
for YAML.
>
> 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
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
--
Thanks,
Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120613/59c3a5bd/attachment.html>
More information about the cfe-dev
mailing list