Commit Graph

7 Commits

Author SHA1 Message Date
Sean Callanan 558e52c108 [build-script] Bring in modernizations from downstream:
- Don't do any checks of the current SCM repository if the
  llvm repositories are already there.  Useful for bots.
- When symlinking, remove old symlinks.
- Support loading build-script as a library, not necessarily
  under Xcode.
- Stringify args before passing them to subprocess.

llvm-svn: 309631
2017-07-31 21:50:00 +00:00
Enrico Granata f8802502f2 Add an accessor to get the value of RC_PLATFORM_NAME at build time
llvm-svn: 282310
2016-09-23 22:30:08 +00:00
Enrico Granata 5edef42e7f Actually, do it this way because I will want to know if I am in a host build elsewhere too
llvm-svn: 282179
2016-09-22 17:59:58 +00:00
Enrico Granata 9a4a6b260f The host version of lldb always builds for macosx
llvm-svn: 282178
2016-09-22 17:47:33 +00:00
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort.  Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit.  The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

    find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
    find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit.  There are alternatives available that will attempt
to look through this change and find the appropriate prior commit.  YMMV.

llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Stephane Sezer c691b14a41 Use shallow clones in build-llvm.py.
Summary:
This makes cloning (and therefore the whole build) faster.
The checkout step goes from ~4m to ~30s on my host.

Reviewers: tfiala

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D17425

llvm-svn: 262513
2016-03-02 20:53:19 +00:00
Todd Fiala 2c0802c559 modify Xcode build to use cmake/ninja for internal llvm/clang
This change restores the Xcode build to working after Makefile support
was stripped from LLVM and clang recently.

With this change, the Xcode build now requires cmake (2.8.12.2+).
The cmake must either be on the path that Xcode sees, or it must
exist in one of the following locations:

* /usr/local/bin/cmake
* /opt/local/bin/cmake
* $HOME/bin/cmake

If the ninja build tool is present on the path, it will be used.
If not, ninja will be cloned (via git), bootstrap-built, and
used for the llvm/clang build.

LLDB now requires a minimum deployment target of OS X 10.9.  Prior
to this, it was 10.8.  The llvm/clang cmake build will not run
with Xcode 7.2 or Xcode 7.3 beta's compiler with the minimum
deployment target set to anything lower than 10.9.  This is
related to #include <atomic>.

When llvm or clang source code does not exist in the lldb tree,
it will be cloned via git using http://llvm.org/git/{project}.git.
Previously it used SVN.  If this causes any heartache, we can
make this smarter, autodetect an embedded svn and use svn instead.
(And/or use SVN if a git command is not available).

This change also fixes an lldb-mi linkage failure (needed
libncurses) as exposed by one of the LLVM libs.

llvm-svn: 259027
2016-01-28 07:36:44 +00:00