[cfe-dev] Compiling a simple Win32 program

Wed Jun 13 19:01:22 PDT 2012

On Wed, Jun 13, 2012 at 8:51 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote:

> 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.
>

I have to say that I'm very hesitant about using PATH as the determining
factor.

There are really two separate usages of clang here: (1) as a drop-in
replacement for cl.exe where PATH, INCLUDE, and LIB should be respected,
and (2) as a stand-alone compiler that accepts its own options and
conventions.  For (2), which seems to be the focus here, I think a
combination of target triple and sysroot should be sufficient, as the
triple will tell you if you're targeting MSVC or MinGW, and i686 vs x86_64,
and a sysroot can be used to specify the specific MinGW headers/libraries
you want to use.  This would allow you to target different MinGW
installations without messing with environment variables.

I'm not sure what you mean by "munging about the piggyback approach on
Windows."

>
>
> 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!
>

-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120613/9520f2fd/attachment.html>