We probably just need to touch LLVM's configure this time to work around the
totally inadequate Makefile build server integration.
This reverts commit r210314.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210320 91177308-0d34-0410-b5e6-96231b3b80d8
This will unbreak clang vendor builds as a follow-up to r210238, now that we
can't poke into LLVM's private config.h (nor should the string be exposed by
llvm-config.h).
This hopefully removes for good the last include of LLVM's config.h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210313 91177308-0d34-0410-b5e6-96231b3b80d8
I've already spoken to Alp and he signed off on making this one change, so that our buildbots
go green in the short term.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210238 91177308-0d34-0410-b5e6-96231b3b80d8
This corrects long-standing misuses of LLVM's internal config.h.
In most cases the public llvm-config.h header was intended and we can now
remove the old hacks thanks to LLVM r210144.
The config.h header is private, won't be installed and should no longer be
included by clang or other modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210145 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
If you're using git-svn, the clang and llvm repository will typically
map to a different revision.
Before we had:
clang version 3.1 (trunk 152167 trunk 152162)
After this change:
clang version 3.1 (trunk 152167) (llvm/trunk 152162)
So it's self-descriptive with an extra parens group. Which is more
compatible with version string parsers is probably debatable, but this
style was requested.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152183 91177308-0d34-0410-b5e6-96231b3b80d8
the version information, to help prevent user confusion about vendor version
numbers vs. LLVM version numbers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115915 91177308-0d34-0410-b5e6-96231b3b80d8
- I don't like returning StringRef's ever, unless it is actually important for
performance, which it isn't here.
- Also, stop validating getClangRevision to be an integer, I don't see a good
reason to do this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@115071 91177308-0d34-0410-b5e6-96231b3b80d8
(even if it is defined). This fixes the issue of this function
returning '0' when SVN_VERSION is defined to be "".
Fixes: <rdar://problem/7663667>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97620 91177308-0d34-0410-b5e6-96231b3b80d8
every time they are called:
getClangRevision()
getClangFullRepositoryVersion()
getClangFullVersion()
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96033 91177308-0d34-0410-b5e6-96231b3b80d8
have it return a StringRef instead of an integer (to be more VCS
agnostic).
(2) Add getClangFullRepositoryVersion(), which contains an
amalgamation of the repository name and the revision.
(3) Change PCH to only emit the string returned by
getClangFullRepositoryVersion() instead of also emitting the value
of getClangSubversionRevision() (which has been removed). This is
functionally equivalent.
More cleanup to version string generation pending...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94231 91177308-0d34-0410-b5e6-96231b3b80d8
branch/revision information. Use that information in the driver,
rather than one-off branch/revision computation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83321 91177308-0d34-0410-b5e6-96231b3b80d8
Paul Robinson