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.
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'.
Is it worth while to move CPP to the ToolChain infra?
Regards, Ed.
Hi Edward
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.
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?
Thanks
Hi G M,
Hi Edward
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.
Hi Edward
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.
I can't fully visualize the problem (my fault not yours) but if this helps:
If it's just _LIBCPP_WEAK that is the problem because it's missing for you
(and for any other case I wouldn't recommend this), my guess is that you
could safely copy the _LIBCPP_WEAK definition from __config into the other
__config that doesn't have it.
_LIBCPP_WEAK was only put In to allow MSVC to build libcxx. MSVC defines it
as nothing always and the g++ and clang++ definition Is attribute weak.
_LIBCPP_WEAK was just put in to split up another macro that contained two
gcc/clang attributes (used in new.cpp etc.). MSVC understood one and not
the other and the one it didn't understand it didn't need. So _LIBCPP_WEAK
was born to hold that other attribute for GCC/Clang and be nothing for MSVC.
So if the problem is simply LIBCPP_WEAK is not defined, you could define it
and everything else should work.
This assumes you are only interested in g++ clang++.
Sorry if this doesn't help you. I don't know what else to suggest. I can't
quite visual the problem.
I imagine even if this does help it's only a short term solution as more
changes will come that will put you in the same situation.
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.
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;
}
}
}
It is used by Solaris as well.
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.
Solaris is pretty well defined. What would you lose if I removed it? Could we lift it to the ToolChain* files?
-- Ed.
What is currently there for Solaris is not well defined at all, and is
actually a mess with hardcoded paths pointing to soon to be obsolete
GCC versions and complete lack of dynamic discovery of Solaris GCC
runtime and header files locations.
void InitHeaderSearch::AddGnuCPlusPlusIncludePaths();
void InitHeaderSearch::AddDefaultCIncludePaths();
void InitHeaderSearch::AddDefaultCPlusPlusIncludePaths();
These are useful and we use them in Solaris.
You could move them to ToolChain* but i'm not at all sure that this
won't result in every single ToolChain having to define its own
include path search, ending up duplicating code ...
I know InitHeaderSearch isn't pretty, but at least its mess is
localized - and given that it's acting like a swiss-army-knife for
many platforms, i'd expect it to be quite messy 