[cfe-dev] Compiling a simple Win32 program
Mikael Lyngvig
mikael at lyngvig.org
Wed Jun 13 17:51:21 PDT 2012
Michael Spencer said this earlier:
There is a strong aversion to text config files for toolchains
unless absolutely
necessary.
So I think it is better to look for a path that involves one or more
environment variables (Microsoft's tools use PATH for binaries, LIB for
libraries, and INCLUDE for headers). Or, as I suggested, simply mandate
that the fictitous -toolchain option be specifed when using
Clang-piggybacks-MinGW on Windows. All these problems will go away in the
unofficial Clangwin distro that I am working on: There will only be Clang
and the correponding MinGW headers and libraries. MinGW is public domain
so no problems in doing that. I don't understand at all, why we keep
munging about with the piggyback approach on Windows. It makes sense on
Unix, yes, but not on Windows. On Windows a translator is supposed to
include everything that it needs: the translater, its tools, a runtime
library, and the necessary interface files.
2012/6/14 Jon <jon.forums at gmail.com>
> On Wed, Jun 13, 2012 at 5:40 PM, Justin Holewinski
> <justin.holewinski at gmail.com> wrote:
> > 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.
>
>
> No kidding, that's great. By chance is it based upon
> http://pyyaml.org/wiki/LibYAML
>
> Oh hell, time to get smart on the internals and find time to work up a
> prototype for review.
>
> To be clear, I currently view this YAML toolchain file idea as a
> complexity reducer for whatever, if anything, gets baked into the core
> code. Rather than the core code becoming overly complex by *trying* to
> deal with custom msys/mingw/mingw-w64 installs, support
> "non-canonical" msys/mingw installs (define one from clang's pov and
> move on) by allowing `-gcc-toolchain` to prepend the info onto
> existing clang data structures.
>
> The toolchain file isn't yet another required config file, rather,
> it's an optional way to provide *controlled* buildtime overrides. Very
> similar to how one uses cmake toolchain files for cross-compiling.
>
> This toolchain file idea appears primarily useful for msys/mingw-based
> toolchains given the standardized structure of MSVC.
>
> Before this little siren song gets too tempting, I'd like to hear from
> some of the core clang decision makers as to whether the idea looks
> promising enough to invest more time into. If the idea has legs, but
> needs refinements before it could be accepted, what are the specific
> refinements? (assume someone(s) will work up an actual prototype if
> interested enough)
>
> Jon
>
>
>
> >>
> >> 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/20120614/3dd599e5/attachment.html>
More information about the cfe-dev
mailing list