[cfe-dev] Removing InitHeaderSearch

[Edward Meewis]

Yeah,

I use Qt quite a lot, so that's an other one. It is a big mess indeed.

For now, I'll abandon nuking InitHeaderSearch until I've figured out the 
intricacies of Mingw builds. It is just another toolchain, so how hard 
can it be?

;-) Ed.

On 16/10/2013 00:35, Yaron Keren wrote:
> 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 
> <mailto: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 at extraordinarymachine.nl>
>         <mailto:ed at extraordinarymachine.nl
>         <mailto: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 <mailto:cfe-dev at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>