[cfe-dev] Removing InitHeaderSearch

[Yaron Keren]

MingW does use InitHeaderSearch to populate the include directories.
Frankly, between the C, C++ headers and the hardcoded version directories
it's a big mess.

Regrading the MingW version, practically I found three popular
distributions.

1) http://www.mingw.org/
2) http://tdm-gcc.tdragon.net/
3) http://sourceforge.net/projects/mingwbuilds/

The first two are quite easy to support since they are installed to a fixed
default directory. Code for the C includes would be:
      AddPath("c:/mingw/include", System, false);
and
      AddPath("c:/TDM-GCC-32/include", System, false);
respectively.  Library code would be similar.

mingw-builds is smarter installing into different directories based on gcc
version, thread package and EH method. So that you can have multiple
versions of mingw-builds installed and choose between them by changing the
PATH only. I wrote some not-very-elegant code (below) for the C includes of
mingw-builds, I think it's not committed to svn.

For C++ headers, a decision to be made is if the clang+MingW uses by
default libstdc++ or libcxx headers and if libcxx, where it is to be found.
This may be changed later by the user with -nostdinc and such but it is an
headache of flags. Maybe a command line flag?

Yaron

      // mingw-builds include path.
      // Recursively search all dirs for i686-w64-mingw32, include below.
      llvm::error_code EC;
      for (llvm::sys::fs::recursive_directory_iterator
               Dir("c:\\Program Files (x86)\\mingw-builds", EC),
           DirEnd;
           Dir != DirEnd && !EC; Dir.increment(EC)) {
        std::string DirName = Dir->path();
        if (llvm::sys::fs::is_directory(DirName)) {
          if (DirName.find("i686-w64-mingw32") != std::string::npos) {
            SmallString<512> P = DirName;
            llvm::sys::path::append(P, "include");
            AddPath(P.str(), System, false);
            // Stop searching upon first find.
            break;
          }
        }
      }








2013/10/16 Edward Meewis <ed at extraordinarymachine.nl>

> Hi G M,
>
>
> On 15/10/2013 22:56, G M wrote:
>
>> Hi Edward
>>
>> On Wed, Oct 16, 2013 at 9:40 AM, Edward Meewis <
>> ed at extraordinarymachine.nl <mailto:ed@**extraordinarymachine.nl<ed at extraordinarymachine.nl>>>
>> wrote:
>>
>>     Hi,
>>
>>     I was looking into polishing up the header inclusion for FreeBSD,
>>     due to some cmake build issues I have when building the the latest
>>     libcxx with the latest clang.
>>
>> I'm curious what the cmake issues are.
>>
>
> I build clang ToT and libcxx with the previous clang-ToT, using the
> previous libcxx. Sometimes the introduction of new macros, e.g., _LIB_WEAK,
> breaks the build. The cause is subtle: I have to point CXX to
> -I/usr/local/include/c++/v1, but when libcxx is build this needs to be
> overridden to $MYLIBCXXLIB/include when libcxx is built. -nostdcxxinc is no
> help here, because I had to set it explicitly.
> I can work around it by pointing the build to $MYLIBCXXLIB/include, but
> that's not very nice. New headers with old libraries usually spell disaster.
>
>
>
>>     It seems that the InitHeaderSearch is almost obsolete, I think
>>     that most of the header search path information has moved to the
>>     Frontend/Tool(Chain)(s) files.
>>
>>     It turns out that (naively) removing InitHeaderSearc.cpp broke the
>>     CPP init and consequently 'diagtool'.
>>
>> I think InitHeaderSearch is needed by mingw tool chain at least, maybe
>> others.  It could be cleaned up but the functionality is needed for now.
>>
>>
>>     Is it worth while to move CPP to the ToolChain infra?
>>
>> What does that mean in practice?
>>
>
> Don't know yet. I guess defining a mingw toolchain in ToolChains, that
> includes the necessary funtionality, but the miriad of MinGW versions
> scares me a bit.
>
>>
>> Thanks
>>
>
> ______________________________**_________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-dev<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131016/7f2c3772/attachment.html>