[cfe-dev] Compiling a simple Win32 program

[Mikael Lyngvig]

not split(os.sep).  Haven't coded in Pythonf or a few years, but you know
what I mean: os.something, the PATH separator.

2012/6/14 Mikael Lyngvig <mikael at lyngvig.org>

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



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