[cfe-dev] Compiling a simple Win32 program

[Mikael Lyngvig]

Not me, I haven't.  Didn't even know about -gcc-toolchain until you
mentioned it.  I am looking at the clang driver source right now, but
somehow I doubt I'll figure out where all this leads before Nikola has an
answer ready.  (This is my first real dip within the Clang sources.)

2012/6/13 Jon wrote:

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120613/92b89fa7/attachment.html>