[llvm-bugs] [Bug 26751] New: clang-cl: Come up with a way to do the equivalent of %INCLUDE% via command-line flags

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26751

            Bug ID: 26751
           Summary: clang-cl: Come up with a way to do the equivalent of
                    %INCLUDE% via command-line flags
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

clang-cl currently supports a bunch of magic env vars, like cl.exe. Passing
things in env vars is messy (for example: if you want to use clang-cl on Linux,
should the env var item separator be : or ;?), so we should have the ability to
do the same with flags.

I thought just exposing -isystem and then passing one -isystem flag per INCLUDE
entry would be enough, but that's sadly not the case:

1. If I misspell the -isystem flag to point to a nonexistent directory, they're
ignored and the "real" system includes are still picked up. -nostdlibinc fixes
that, but clang-cl doesn't expose that. We could expose this flag too, seems
like a good and easy fix.

2. But even then, the -isystem flags are now searched before the built-in
headers, which has the effect of e.g. `#include <stddef.h>` picking up the msvs
header instead of clang's version (and now offsetof is no longer constexpr
etc). I guess one fix for this would be to add an explicit -isystem flag
pointing to clang's builtin header dir, but this is getting a bit ugly.


Does anyone happen to have better suggestions on how to get the exact same
effect as setting %INCLUDE% with flags?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160226/7ef6080f/attachment.html>