[cfe-dev] Compiling a simple Win32 program

Wed Jun 13 17:19:52 PDT 2012

I think the "which version" solves itself if you use the algorithm I
proposed:

paths = os.environ["PATH"].split(os.sep)
for path in paths:
    # todo: clean up path and ignore empty path elements
    if os.path.exist(path + "cl.exe"):
        return ( path, MSVC )
    elif os.path.exist(path + "g++.exe"):
        return ( path, GCC )
throw Error("Unknown toolchain - use -toolchain option to specify root of
your toolchain.")

Then the user just needs to be careful in setting up the path, something
that we all have to be with Clang, and everything works very sensibly and
logically.

On Windows, the PATH rules.  There are as a rule of thumb no hard-coded
paths and everybody's supposed to use argv[0] to locate their data files.
 Obviously, that does not go well with Clang, but that's also part of why I
am pushing for a Windows-style all-included binary release of Clang for
Windows (something I am working on).

As for the guesswork code, well, I never liked such code.  It always ends
up biting somebody in a soft spot.  Much better is to mandate that the user
explicitly specify the fictitious -toolchain or -tooldir option on Windows,
even though this is less than perfect.  Perhaps we could introduce a
sensible environment variable?  CLANG_TOOLDIR or so.  That's also very
Windows-like.  And that wouldn't require any configuration files.

2012/6/14 Michael Spencer <bigcheesegs at gmail.com>

> On Wed, Jun 13, 2012 at 5:09 AM, Nikola Smiljanic <popizdeh at gmail.com>
> wrote:
> > I think there is more than one issue here.
> >
> > These things are still unclear to me:
> > 1. If both VS and MinGW are installed, which toolchain should Clang use
> and
> > how to decide?
>
> I would like to follow the principle of least surprise here. What do
> users expect? MSVC has a well established way of picking the toolchain
> to use based on bat files but I'm not sure how MinGW users are used to
> dealing with multiple versions of the toolchain. There's also no
> precedent for a tool that can work with either.
>
> > 2. How to obtain the target triple once we've selected the toolchain?
> Right
> > now Clang selects the toolchain based on the default target triple
> (comming
> > from config.h when Clang is compiled).
>
> This is similar to the issues above. What does the user expect? Again
> MSVC uses bat files, and I have no idea how MinGW handles this.
>
> I feel that basing this choice on how clang was compiled is the wrong
> way to do it, as we currently end up often making the obviously wrong
> choice.
>
> > 3. How to decide what the target platform is when using either mingw-w64
> or
> > multiple mingw installations? For VS, toolchains for different targets
> are
> > in different directories and this is easy to detect, but I don't know how
> > this exactly works for MinGW/MinGW-W64. I think they have an executable
> for
> > every target?
>
> Isn't this exactly the same as choosing the target triple? Also I
> assume by platform you only mean x86 vs x86-64.
>
> > Things I do know, at least partially:
> > - If multiple versions of VS are installed, Clang will select the first
> one
> > in the PATH.
>
> It's actually currently a lot more complicated than this. First it
> adds %INCLUDE%, then it tries %VCINSTALLDIR%, then it tries the
> registry to pick the highest version, then it uses
> %VS{80|90|100}COMNTOOLS% depending on the version it was compiled
> with, then any of them. And that's just for the VS paths. It then goes
> and looks for the Windows SDK in the registry, which is already added
> to %INCLUDE% by vcvars.bat. So we actually end up with multiple
> versions of MSVC on the path. However the link.exe it picks is always
> the first one on the path, which always uses %LIB% to look for
> libraries.
>
> This clearly needs to be cleaned up :P.
>
> > - Same logic should apply for multiple MinGW/MSYS versions. "which gcc"
> > should give back the active toolchain. The question about the target
> still
> > remains.
>
> I agree in part. I do however wonder how we would handle a distro of
> MinGW that completely removes gcc in favor of clang.
>
> > - In the case of VS the target is decided based on the toolchain's
> directory
> > (the one in VC\bin targets x86, etc.)
>
> The target is decided by the binary yes, but the headers and libs are
> decided by %INCLUDE% and %LIB%.
>
> > A bit unrelated issue is the one about MinGW toolchain support inside
> Clang
> > codebase, or the lack thereof. This is why the hardcoded paths are still
> > needed in InitHeaderSearch. This is something that needs to be done, I
> had a
> > look into it but never found enough time to do something useful. I think
> > this is the first thing to work on If you're interested in better MinGW
> > support. For more info look
> > here http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-March/020235.html
>  (see
> > reply from Chandler).
>
> Agreed that this all goes in the driver. But selecting the exact
> version to use is a bit more complicated than with gcc on Linux. At
> least from what I've seen.
>
> > As for the external text files, I don't think a feature like that could
> be
> > implemented without discussing it first with larger community. Just
> > something to take into account if you had any plans to work on something
> > like this. This is just my personal impression after following the list
> for
> > some time :)
>
> There is a strong aversion to text config files for toolchains unless
> absolutely necessary.
>
> - Michael Spencer
>
> > On Wed, Jun 13, 2012 at 10: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!
> >
> >
>

-- 
-- Love Thy Frog!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120614/603e7b97/attachment.html>