As discovered in D56774 the command line gets to long, so use a response file
to give the script the libs. This change has been tested and is confirmed
working for me.
Commited on behalf of Jakob Bornecrantz.
Differential Revision: https://reviews.llvm.org/D56781
llvm-svn: 356443
Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010
Code like:
```
if(true) var++;
else {
var--;
}
```
is reformatted to be
```
if (true)
var++;
else {
var--;
}
```
Even when `AllowShortIfStatementsOnASingleLine` is true
The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine
This suppresses the clause prevents the merging of the if when there is a compound else
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087
llvm-svn: 356029
Allow the use of ninja instead of make. This is useful on some
platforms where we'd like to be able to limit the number of link jobs
without slowing down the other steps of the release.
This patch adds a -use-ninja command line option, which sets the
generator to Ninja both for LLVM and the test-suite. It also deals with
some differences between make and ninja:
* DESTDIR handling - ninja doesn't like this to be listed after the
target, but both make and ninja can handle it before the command
* Verbose mode - ninja uses -v, make uses VERBOSE=1
* Keep going mode - make has a -k mode, which builds as much as possible
even when failures are encountered; for ninja we need to set a hard
limit (we use 100 since most people won't look at 100 failures anyway)
I haven't tested with gmake.
llvm-svn: 353685
They were breaking the Windows build when using MSBuild, see the
discussion on D56781.
r351833: "Use response file when generating LLVM-C.dll"
> Use response file when generating LLVM-C.dll
>
> As discovered in D56774 the command line gets to long, so use a response file to give the script the libs. This change has been tested and is confirmed working for me.
>
> Commited on behalf of Jakob Bornecrantz
>
> Differential Revision: https://reviews.llvm.org/D56781
r352250: "Build LLVM-C.dll by default on windows and enable in release package"
> Build LLVM-C.dll by default on windows and enable in release package
>
> With the fixes to the building of LLVM-C.dll in D56781 this should now
> be safe to land. This will greatly simplify dealing with LLVM for people
> that just want to use the C API on windows. This is a follow up from
> D35077.
>
> Patch by Jakob Bornecrantz!
>
> Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 352492
With the fixes to the building of LLVM-C.dll in D56781 this should now
be safe to land. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.
Patch by Jakob Bornecrantz!
Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 352250
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This broke the build, ending up with too long command-lines when invoking gen-mscv-exports.py.
> As it says in the subject, should have gone long enough now that this
> should be safe. This will greatly simplify dealing with LLVM for people
> that just want to use the C API on windows. This is a follow up from
> D35077.
>
> Patch by Jakob Bornecrantz!
>
> Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 351329
As it says in the subject, should have gone long enough now that this
should be safe. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.
Patch by Jakob Bornecrantz!
Differential revision: https://reviews.llvm.org/D56774
llvm-svn: 351324
Make sure all print statements are compatible with Python 2 and Python3 using
the `from __future__ import print_function` statement.
Differential Revision: https://reviews.llvm.org/D56249
llvm-svn: 350307
Summary:
This reverts r346122 now that the failing tests have been
disabled. Depends on D54353.
Reviewers: aheejin, dschuff
Subscribers: fedor.sergeev, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D54354
llvm-svn: 346559
This change updates the release script to use svnmucc to create all
the branches with one commit.
This will ensure that the git tag won't bounce around if the git
migration runs in-between separate commits creating a branch.
Additionally, update the list of projects to include all of the
projects in the monorepo, plus test-suite.
Differential Revision: https://reviews.llvm.org/D53467
llvm-svn: 346550
Summary:
This script allows you to use git to backport a commit to a stable
branch while generating the exact same commit message (ignoring
whitespace) that you would get from using the merge.sh script with svn.
Reviewers: hansw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47760
llvm-svn: 334568
I don't think anyone ever got this to work, what with getting exactly
the right Python dependency and so on. Removing it simplifies the
script, removes a number of hairy dependencies, and cuts ~30 MB off the
installer size.
llvm-svn: 327835
On FreeBSD, it is currently not possible to build libcxxabi and link
against it, so we have been building releases with -no-libs for quite
some time.
However, libcxx and libunwind should build without problems, so provide
an option to skip just libcxxabi.
llvm-svn: 322875
Summary:
This will be used instead of the url field to track which commits need
to be merged.
This patch also drops support for version 1.x of the bugzilla CLI tool.
Reviewers: hansw, hans
Reviewed By: hans
Subscribers: hans, llvm-commits
Differential Revision: https://reviews.llvm.org/D37786
llvm-svn: 313334
Summary:
We want to catch failures early before do the full 3 stage build.
The goal here is to avoid running through the whole build process and have
it fail at the end (and not create the binary packages), just because
some prerequisites failed to install.
Reviewers: rovka, hans
Reviewed By: hans
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36422
llvm-svn: 310939
Summary:
scudo_utils.cpp.o from compiler-rt has one of the host compiler's builtin
include paths stored in the .debug_line section. So we need to do
sed 's,Phase1,Phase2,g` on the Phase2 object file so it matches Phase3.
Reviewers: hans
Reviewed By: hans
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34989
llvm-svn: 308912
Summary: We were using the system compiler to run the test suite.
Reviewers: hansw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34246
llvm-svn: 305525
Summary: We aren't actually building the test suite, so this isn't needed.
Reviewers: rengolin, hansw
Reviewed By: rengolin
Subscribers: rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D29840
llvm-svn: 305017
Summary:
This script will automatically create a new stable merge request bug in
bugzilla for the given svn revision and release number.
Reviewers: hans
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30905
llvm-svn: 298705
In r293373 we switched the build to linking dynamically against the
Universal CRT and include the redistributables in the installer.
However, clang-format.exe is copied into the vsix and needs to be
statically linked. This commit makes us build the plugin in a separate
step that uses static linking.
llvm-svn: 294513
Building lld is enabled by default, but it can be disabled using the
-no-lld option.
Reviewers: tstellarAMD, rengolin, hans
Reviewed By: hans
Subscribers: grosser, wdng, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D29539
llvm-svn: 294102
In order to make sure that LLVM continues to work on machines that do not have the Universal CRT yet,
we'll need to ship a copy of UCRT in the Windows installation package. Fortunately, CMake 3.6+ already
supports app-local deployment of UCRT dlls, we just need to turn this on.
Differential Revision: https://reviews.llvm.org/D29146
llvm-svn: 293373
