[cfe-dev] Header Search for Linux and Win32

[João Matos]

I've had the same problem in my Clang-based tools.

I think we should either move all platform-specific include code out of
Frontend into a separate library or move the Win32 header search code back
into Frontend. Right now we have bits of it into different libraries and
it's confusing and hard to figure out.

Another option would be move most of it into some configuration files
(having hardcoded paths in the source for things like MinGW locations does
not make much sense going forward).

The way I've "solved it" in the meanwhile, was by adding a function to
access the Win32 platform headers search code in the driver (see the
attached patch).

On Sun, Aug 26, 2012 at 5:08 PM, Larry Olson <loarabia at hotmail.com> wrote:

> I've been maintaining some clang / llvm tutorials that show how to use the
> basic libraries from clang on github (
> https://github.com/loarabia/Clang-tutorial). Because of a pull request
> this week to make the tutorials handle headers on Linux, I noticed that the
> code has drifted for handling some platforms' headers.
>
> In a nutshell, header handling of platform headers on Win32 and Linux
> Targets has moved out of InitHeaderSearch and into the Driver. The comments
> in the file read that the long term goal is to move all header handling out
> of InitHeaderSearch.
>
> My question then is, what is the right way for folks using the basic
> libraries to setup the full toolchain including headers search. Is that a
> scenario intended to be supported elsewhere?
>
> I can create a component that does basically what the Driver and ToolChain
> code does together but before I do that, I want to make sure that I am not
> overlooking the Intended Way (TM).
>
> Thanks,
> Larry
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


-- 
João Matos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120826/bc265d7f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Expose-function-to-get-Windows-system-include-paths.patch
Type: application/octet-stream
Size: 4746 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120826/bc265d7f/attachment.obj>