8ce6d214aef65ea1421eb11e84980dfa4da429b8 |
|
13-Mar-2012 |
NAKAMURA Takumi <geek4civic@gmail.com> |
[msvc] Honor %INCLUDE%. It should know essential search paths with vcvarsall.bat. FYI, On VS10, %INCLUDE% contains; (VS10)\VC\INCLUDE (VS10)\VC\ATLMFC\INCLUDE (SDK70A)\include On VS11, (VS11)\VC\INCLUDE (VS11)\VC\ATLMFC\INCLUDE (SDK80)\include\shared (SDK80)\include\um (SDK80)\include\winrt FIXME: It may be enabled also on mingw. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152589 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Driver/WindowsToolChain.cpp
|
30660a898545416f0fea2d717f16f75640001e38 |
|
06-Mar-2012 |
Ted Kremenek <kremenek@apple.com> |
Add new code migrator support for migrating existing Objective-C code to use the new Objective-C NSArray/NSDictionary/NSNumber literal syntax. This introduces a new library, libEdit, which provides a new way to support migration of code that improves on the original ARC migrator. We now believe that most of its functionality can be refactored into the existing libraries, and thus this new library may shortly disappear. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152141 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Driver/WindowsToolChain.cpp
|
69d3b4f7c9fa818d2536b4f1b220b942ae392128 |
|
01-Feb-2012 |
Dylan Noblesmith <nobled@dreamwidth.org> |
include clang's config.h unconditionally And remove HAVE_CLANG_CONFIG_H, now that the header is generated in the autoconf build, too. (clang r149497 / llvm r149498) Also include the config.h header after all other headers, per the LLVM coding standards. It also turns out WindowsToolChain.cpp wasn't using the config header at all, so that include's just deleted now. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149504 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Driver/WindowsToolChain.cpp
|
1d16f0f805c2a3e2198a87154990347b2759f6bd |
|
31-Jan-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Revert r149083 which is not the direction we're going in the Clang driver based on discussions with Doug Gregor. There are several issues: 1) The patch was not reviewed prior to commit and there were review comments. 2) The design of the functionality (triple-prefixed tool invocation) isn't the design we want for Clang going forward: it focuses on the "user triple" rather than on the "toolchain triple", and forces that bit of state into the API of every single toolchain instead of handling it automatically in the common base classes. 3) The tests provided are not stable. They fail on a few Linux variants (Gentoo among them) and on mingw32 and some other environments. I *am* interested in the Clang driver being able to invoke triple-prefixed tools, but we need to design that feature the right way. This patch just extends the previous hack without fixing the underlying problems with it. I'm working on a new design for this that I will mail for review by tomorrow. I am aware that this removes functionality that NetBSD relies on, but this is ToT, not a release. This functionality hasn't been properly designed, implemented, and tested yet. We can't "regress" until we get something that really works, both with the immediate use cases and with long term maintenance of the Clang driver. For reference, the original commit log: Keep track of the original target the user specified before normalization. This used to be captured in DefaultTargetTriple and is used for the (optional) $triple-$tool lookup for cross-compilation. Do this properly by making it an attribute of the toolchain and use it in combination with the computed triple as index for the toolchain lookup. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149337 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Driver/WindowsToolChain.cpp
|
34144f67610be0ac6cb0d85d77bd57662b9232b9 |
|
26-Jan-2012 |
Joerg Sonnenberger <joerg@bec.de> |
Keep track of the original target the user specified before normalization. This used to be captured in DefaultTargetTriple and is used for the (optional) $triple-$tool lookup for cross-compilation. Do this properly by making it an attribute of the toolchain and use it in combination with the computed triple as index for the toolchain lookup. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149083 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Driver/WindowsToolChain.cpp
|
4d7ff6e8639bdce74e39b90370729ad0179ebcca |
|
25-Jan-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Switch the ToolChain types to all store a Driver reference rather than a HostInfo reference. Nothing about the HostInfo was used by any toolchain except digging out the driver from it. This just makes that a lot more direct. The change was accomplished entirely mechanically. It's one step closer to removing the shim full of buggy copy/paste code that is HostInfo. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Driver/WindowsToolChain.cpp
|
79cbbdc8affe52591f7ee487a789639aa38331ec |
|
18-Dec-2011 |
Chandler Carruth <chandlerc@gmail.com> |
Split the Windows toolchain definition into its own file. This is especially nice as the Windows toolchain needs the windows header files, and has lots of platform specific hooks in it. To facilitate the split, hoist a bunch of file-level static helpers into class-level static helpers. Spiff up their doxygen comments while there as they're now more likely to be looked up via docs. Hopefully, this will be followed by further breaking apart of the toolchain definitions. Most of the large and complex ones should likely live on their own. I'm looking at you Darwin. ;] git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146840 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/lib/Driver/WindowsToolChain.cpp
|