[cfe-dev] Compiling a simple Win32 program
Mikael Lyngvig
mikael at lyngvig.org
Wed Jun 13 14:43:53 PDT 2012
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 :-)
2012/6/13 Justin Holewinski <justin.holewinski at gmail.com>
> 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
>
>
--
-- Love Thy Frog!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120613/98a5d84e/attachment.html>
More information about the cfe-dev
mailing list