[cfe-dev] Compiling a simple Win32 program

[Mikael Lyngvig]

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
>



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