summaryrefslogtreecommitdiffstats
path: root/llvm/tools/msbuild
Commit message (Collapse)AuthorAgeFilesLines
* vs integration: bump version nbrHans Wennborg2019-06-191-1/+1
| | | | llvm-svn: 363769
* Revert r359557 "vs integration: vs2019 support"Hans Wennborg2019-06-191-7/+7
| | | | | | | | | | Turns out this worked on my machine because I still had VS2017 installed, but it didn't actually work in general. Since the extension is unmaintained and MS is doing their own LLVM toolset integration for VS2019, let's just revert. llvm-svn: 363768
* vs integration: vs2019 supportHans Wennborg2019-04-301-7/+7
| | | | llvm-svn: 359557
* vs integration: Use llvm-lib for librarianRussell Gallop2019-04-293-0/+24
| | | | | | | | | | | | | | This uses llvm-lib.exe for the librarian instead of Visual Studio provided lib.exe. Without this it is not possible to create static libraries with -flto using the plugin. Original patch by Steven Noonan This fixes: PR41147 Differential Revision: https://reviews.llvm.org/D61193 llvm-svn: 359430
* Fix typos throughout the license files that somehow I and my reviewersChandler Carruth2019-01-211-1/+1
| | | | | | | | | | | all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731
* Install new LLVM license structure and new developer policy.Chandler Carruth2019-01-191-16/+238
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 llvm-svn: 351631
* Update Visual Studio Integration version number.Zachary Turner2018-08-291-1/+1
| | | | | | | This updates the version number in the manifest file to match the SVN revision at which it was committed. llvm-svn: 340938
* Update the Visual Studio Integration from user feedback.Zachary Turner2018-08-273-69/+55
| | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the MSBuild warnings about options that clang-cl ignores. It also adds several additional fields to the LLVM Configuration options page. The first is that it adds support for LLD! To give the user flexibility though, we don't want to force LLD to always-on, and if we're not forcing LLD then we might as well not force clang-cl either. So we add options that can enable or disable lld, clang-cl, or any combination of the two. Whenever one is disabled, it falls back to the Microsoft equivalent. Additionally, for each of clang-cl and lld-link, we add a new configuration setting that allows Additional Options to be passed for that specific tool only. This is similar to the C/C++ > Command Line > Additional Options entry box, but it serves the use case where a user switches back and forth between the toolsets in their vcxproj, but where cl.exe won't accept some options that clang-cl will. In this case you can pass those options in the clang-cl additional options and whenever clang-cl is disabled (or the other toolset is selected entirely), those options won't get passed at all. llvm-svn: 340780
* Set line endings to Windows on MSBuild files.Zachary Turner2018-08-272-252/+252
| | | | | | Normally we force Unix line endings in the repository, but since these are Windows files which are consumed by Microsoft tools that we don't have the source of, we should probably err on the side of caution and force CRLF. llvm-svn: 340776
* vs integration: bump version numberHans Wennborg2018-08-091-1/+1
| | | | llvm-svn: 339330
* vs integration: update the manifest to require VS 2017Hans Wennborg2018-08-091-3/+3
| | | | | | It previously erroneously said only VS2015 was required. llvm-svn: 339329
* Update msbuild integration warnings: Don't warn on /Zi and /XNico Weber2018-08-071-9/+1
| | | | | | | | | | | | | | We do need to map /Zi to /Z7 explicitly for msbuild as explained in this file, but since /Zi is passed by default and since things transparently work fine with it mapped to /Z7, we shouldn't produce effectively inactionable noise for it. Also don't warn on /X since clang-cl supports that (since r326357; the risk of duplicating a bunch of clang-cl driver logic here). https://reviews.llvm.org/D50398 llvm-svn: 339169
* vs integration: bump version numberHans Wennborg2018-08-071-1/+1
| | | | llvm-svn: 339119
* vs integration: update the publisher nameHans Wennborg2018-08-071-1/+1
| | | | llvm-svn: 339118
* vs integration: fix default path to clang-clHans Wennborg2018-08-071-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D50335 llvm-svn: 339117
* Update the LLVM VS integration to sign the assembly.Zachary Turner2018-08-022-9/+10
| | | | llvm-svn: 338740
* Rewrite the VS integration scripts.Zachary Turner2018-07-2023-357/+590
| | | | | | | | | | | | | | | | | | | | | | | This is a new modernized VS integration installer. It adds a Visual Studio .sln file which, when built, outputs a VSIX that can be used to install ourselves as a "real" Visual Studio Extension. We can even upload this extension to the visual studio marketplace. This fixes a longstanding problem where we didn't support installing into VS 2017 and higher. In addition to supporting VS 2017, due to the way this is written we now longer need to do anything special to support future versions of VS as well. Everything should "just work". This also fixes several bugs with our old integration, such as MSBuild triggering full rebuilds when /Zi was used. Finally, we add a new UI page called "LLVM" which becomes visible when the LLVM toolchain is selected. For now this only contains one option which is the path to clang-cl.exe, but in the future we can add more things here. Differential Revision: https://reviews.llvm.org/D42762 llvm-svn: 337572
* Create msbuild only when using MSVCReid Kleckner2017-03-161-1/+1
| | | | | | | | | | | | | | | | | | | Summary: I could be wrong but it seems to have no use for MinGW. Related diff: https://reviews.llvm.org/D29772 Reviewers: chandlerc, rnk Reviewed By: rnk Patch by: Mateusz Mikuła Subscribers: rnk, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D29952 llvm-svn: 297985
* MSBuild integration: fix the loop in install.batHans Wennborg2014-09-302-8/+18
| | | | | | | It would previously not continue the platforms loop unless it could find the latest toolset directory. llvm-svn: 218712
* msbuild integration: remove duplicated lines and BOM from 2014 integration ↵Hans Wennborg2014-07-311-3/+0
| | | | | | (PR20341) llvm-svn: 214435
* Add a VS "14" msbuild toolsetReid Kleckner2014-07-235-0/+75
| | | | | | | | | | | This allows people to try clang inside MSBuild with the VS "14" CTP releases. Fixes PR20341. Patch by Marcel Raad! llvm-svn: 213819
* VS integration installer: set SUCCESS=1 if we find VS 2013Hans Wennborg2014-03-241-2/+3
| | | | | | | | | | Previously we would print an error message on machines where the only VS version we find is 2013, even though we successfully install the integration files for it. Also, we shouldn't have two END labels. llvm-svn: 204629
* MSBuild integration: get the LibraryPath right (PR18707)Hans Wennborg2014-02-132-1/+3
| | | | | | | It was pointing to lib\clang\3.4, but now we're on 3.5. Make CMake insert the right version automatically. llvm-svn: 201363
* VS Integration: install toolsets for x64 too (PR18738)Hans Wennborg2014-02-124-66/+97
| | | | | | | | | This does exactly the same thing as for Win32, except it passes -m64 to the compiler and the files go in a different directory. Differential Revision: http://llvm-reviews.chandlerc.com/D2749 llvm-svn: 201269
* VS integration: use the correct registry key after r195379Hans Wennborg2013-11-221-1/+1
| | | | | | | I changed the registry key in that commit, but forgot to update the integration files. This change makes them use the same variable. llvm-svn: 195479
* vs2013 msbuild integration: add missing .target files, fix typo in CMakeListsHans Wennborg2013-10-143-1/+25
| | | | | | | | This should fix PR17568. Patch by Josh Samuel! llvm-svn: 192610
* Provide msbuild integration for vs2013.Hans Wennborg2013-10-104-1/+49
| | | | | | Patch by Josh Samuel! llvm-svn: 192371
* Fix msbuild integration install script.Hans Wennborg2013-10-101-2/+5
| | | | | | | We previously failed to check whether the SUCCESS variable was set, and would thus always exit with a failure if vs2012 didn't exist. llvm-svn: 192370
* msbuild: Set _MSC_VER to match the CRT we're usingReid Kleckner2013-09-192-0/+10
| | | | | | | | | Various Windows SDK headers use _MSC_VER values to figure out what version of the VC++ headers they're using, in particular for SAL macros. Patch by Paul Hampson! llvm-svn: 191015
* Include an LLVM-vs2012_xp toolset in the MSBuild integrationReid Kleckner2013-09-194-0/+37
| | | | | | Patch by Paul Hampson! llvm-svn: 191010
* msbuild integration: provide separate files for VS2010 and VS2012Hans Wennborg2013-09-066-35/+58
| | | | | | | | | The previous msbuild integration only worked if VS2010 was installed. This patch renames the current integration to LLVM-vs2010 and adds LLVM-vs2012. Differential Revision: http://llvm-reviews.chandlerc.com/D1614 llvm-svn: 190173
* msbuild: Add clang's compiler-rt libs to the LibraryPathReid Kleckner2013-09-051-0/+1
| | | | | | This allows linking libraries like the asan RTL. llvm-svn: 190028
* Substitute LLVM's version into the msbuild property file at config timeReid Kleckner2013-08-293-10/+16
| | | | | | | Requires shuffling the CPack code up before add_subdirectory(tools), but that's where the version settings are anyway. llvm-svn: 189615
* Modified ms-build configuration file to be version locked to the VS2010 ↵Warren Hunt2013-08-291-19/+2
| | | | | | | | toolchain, this avoids conflicts with having VS2012 and Win7SDK used at the same time. llvm-svn: 189613
* Adding VCIncludeDir and WindowsSDKDir to the msbuild configuration file. ↵Warren Hunt2013-08-281-2/+18
| | | | | | | | This allows clang to find windows.h and other files in the sdk and visutal studio includes. llvm-svn: 189528
* cmake: Add msbuild integration to the installHans Wennborg2013-08-283-0/+78
| | | | | | | | | | This adds the msbuild integration files to the install, provides batch scripts for (un)installing it in a convenient way, and hooks up the nsis installer to run those scripts. Differential Revision: http://llvm-reviews.chandlerc.com/D1537 llvm-svn: 189434
* Add xml files for msbuild integrationReid Kleckner2013-08-272-0/+12
These files are intended to live in the msbuild toolset directory, which is somewhere like: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\ v4.0\Platforms\Win32\PlatformToolsets\llvm More work is needed to install them as part of the NSIS installer. Patch by Warren Hunt! llvm-svn: 189411
OpenPOWER on IntegriCloud