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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363768 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359430 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351731 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351631 91177308-0d34-0410-b5e6-96231b3b80d8
This updates the version number in the manifest file to match
the SVN revision at which it was committed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340938 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340780 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@340776 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@339169 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337572 91177308-0d34-0410-b5e6-96231b3b80d8
This allows people to try clang inside MSBuild with the VS "14" CTP
releases.
Fixes PR20341.
Patch by Marcel Raad!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213819 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204629 91177308-0d34-0410-b5e6-96231b3b80d8
It was pointing to lib\clang\3.4, but now we're on 3.5.
Make CMake insert the right version automatically.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201363 91177308-0d34-0410-b5e6-96231b3b80d8
I changed the registry key in that commit, but forgot to update
the integration files. This change makes them use the same variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195479 91177308-0d34-0410-b5e6-96231b3b80d8
We previously failed to check whether the SUCCESS variable was set,
and would thus always exit with a failure if vs2012 didn't exist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192370 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191015 91177308-0d34-0410-b5e6-96231b3b80d8
Requires shuffling the CPack code up before add_subdirectory(tools), but
that's where the version settings are anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189615 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189411 91177308-0d34-0410-b5e6-96231b3b80d8
