Re: [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
Fedora and openSUSE uploaded. On Sat, Aug 22, 2015 at 6:59 AM, Renato Golin wrote: > AArch64 up. All green. > > On 21 August 2015 at 01:51, Hans Wennborg wrote: > > Hello everyone, > > > > 3.7-rc3 has just been tagged. Testers, please test, build binaries, > > upload to the sftp and report results to this thread. > > > > Again, a lot of patches got merged between rc2 and rc3, but hopefully > > nothing that should upset things. > > > > One thing that did change is that the release script now correctly > > symlinks clang-tools-extra into the build. If this causes problems on > > your platform, please just remove it. > > > > This is a release candidate in the real sense: at this point I have > > zero release blockers on my radar. I will now only accept fixes for > > critical regressions, and if nothing comes up, rc3 will be promoted to > > 3.7.0-final. > > > > Documentation and release note patches are still welcome all the way > > up until the final tag goes in. > > > > Issues that were on my radar, but I don't consider blocking: > > > > - Sanitizer test failures on various platforms, e.g. PR24222. We never > > ran these tests in previous releases, so it's not a regression. It > > would be great if the sanitizer folks could look into the test > > failures, but it's not blocking 3.7. > > > > - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in > > __cxa_allocate_exception", Renato will exclude libc++ from his build > > for now. > > > > - Lack of key functions in some Instruction classes causing build > > failures without -fno-rtti > > (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No > > patches have been forthcoming, so this will not get fixed for 3.7. At > > least we correctly report -fno-rtti in llvm-config built with CMake > > now. > > > > - r244221: "[SPARC] Don't compare arch name as a string, use the enum > > instead", owner is unresponsive. > > > > - "[lldb] r245020 - [MIPS]Handle floating point and aggregate return > > types in SysV-mips [32 bit] ABI", owner is unresponsive. > > > > > > Cheers, > > Hans > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
On 21 August 2015 at 21:59, Renato Golin wrote: > AArch64 up. All green. ARM up. All green. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
The problem seems to be caused by the way the symlinks are setup in test-release.sh, e.g. like so: llvm.src/tools/clang -> ../../cfe.src cfe.src/tools/extra -> ../../clang-tools-extra.src When it then tries to access the path llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, it fails. I tried this on both FreeBSD, OSX and Linux, but it fails everywhere. For example, on Linux: $ ls -l ~/foo/llvm.src/tools/clang lrwxrwxrwx 1 dim dim 13 2015-08-22 18:40:16 /home/dim/foo/llvm.src/tools/clang -> ../../cfe.src/ $ ls -l ~/foo/cfe.src/tools/extra lrwxrwxrwx 1 dim dim 27 2015-08-22 18:53:04 /home/dim/foo/cfe.src/tools/extra -> ../../clang-tools-extra.src/ $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling total 16 -rw-r--r-- 1 dim dim 8983 2015-08-22 18:17:18 ApplyReplacements.cpp -rw-r--r-- 1 dim dim 526 2015-08-22 18:17:18 Makefile $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include ls: cannot access /home/dim/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include: No such file or directory Note that llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. goes back to the top level, where *.src is checked out: $ ls -l ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. total 12 drwxr-xr-x 16 dim dim 4096 2015-08-22 18:17:16 cfe.src/ drwxr-xr-x 14 dim dim 4096 2015-08-22 18:40:32 clang-tools-extra.src/ drwxr-xr-x 16 dim dim 4096 2015-08-22 18:13:58 llvm.src/ Of course at a level even below that, there is little chance of an include directory existing. How does anybody else manage to build using the test-release.sh script, and having clang-tools-extra? -Dimitry > On 21 Aug 2015, at 14:09, Dimitry Andric via lldb-dev > wrote: > > Strangely, the clang-tools-extra stuff does build if I manually check it out > like so (without any symlinks): > > .<-- > https://llvm.org/svn/llvm-project/llvm/branches/release_37 > tools/clang <-- > https://llvm.org/svn/llvm-project/cfe/branches/release_37 > tools/clang/tools/extra <-- > https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 > > I'll investigate, because it would be nice to have those tools. > > -Dimitry > >> On 21 Aug 2015, at 13:42, Nikola Smiljanic wrote: >> >> Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior >> to rc3. Just delete it and run script with --no-checkout. >> >> On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric wrote: >> Hm, it does not seem to compile at all here? The build ends with: >> >> In file included from >> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17: >> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10: >> fatal error: 'clang/Tooling/Refactoring.h' file not found >> #include "clang/Tooling/Refactoring.h" >> ^ >> 1 error generated. >> >> Any idea? I had no problems at all with -rc2. >> >> -Dimitry >> >>> On 21 Aug 2015, at 02:51, Hans Wennborg wrote: >>> >>> Hello everyone, >>> >>> 3.7-rc3 has just been tagged. Testers, please test, build binaries, >>> upload to the sftp and report results to this thread. >>> >>> Again, a lot of patches got merged between rc2 and rc3, but hopefully >>> nothing that should upset things. >>> >>> One thing that did change is that the release script now correctly >>> symlinks clang-tools-extra into the build. If this causes problems on >>> your platform, please just remove it. >>> >>> This is a release candidate in the real sense: at this point I have >>> zero release blockers on my radar. I will now only accept fixes for >>> critical regressions, and if nothing comes up, rc3 will be promoted to >>> 3.7.0-final. >>> >>> Documentation and release note patches are still welcome all the way >>> up until the final tag goes in. >>> >>> Issues that were on my radar, but I don't consider blocking: >>> >>> - Sanitizer test failures on various platforms, e.g. PR24222. We never >>> ran these tests in previous releases, so it's not a regression. It >>> would be great if the sanitizer folks could look into the test >>> failures, but it's not blocking 3.7. >>> >>> - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in >>> __cxa_allocate_exception", Renato will exclude libc++ from his build >>> for now. >>> >>> - Lack of key functions in some Instruction classes causing build >>> failures without -fno-rtti >>> (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No >>> patches have been forthcoming, so this will not get fixed for 3.7. At >>> least we correctly report -fno-rtti in llvm-config built with CMake >>> now. >>> >>> - r244221: "
[lldb-dev] EvaluateExpression has trailing error
Hi,
My script is simple enough:
import lldb
def pp(debugger, command, result, internal_dict):
target = debugger.GetSelectedTarget()
process = target.GetProcess()
thread = process.GetSelectedThread()
frame = thread.GetSelectedFrame()
res = frame.EvaluateExpression("%s->dump()" % command)
print >>result, res
def __lldb_init_module(debugger, internal_dict):
debugger.HandleCommand('command script add -f llvm_pp.pp pp')
print "Command pp installed"
However, when I execute it:
(lldb) pp Ty
Fn(Void -> Int)*
=
When I use res.GetSummary() in place of res, I get "None" instead of
the error. What is this trailing data anyway, and how do I get rid of
it?
Thanks.
Ram
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
It's building with this patch now, already at Phase3, so it seems to work: Index: trunk/utils/release/test-release.sh === --- trunk/utils/release/test-release.sh (revision 245679) +++ trunk/utils/release/test-release.sh (working copy) @@ -266,43 +268,36 @@ check_valid_urls for proj in $projects ; do -if [ -d $proj.src ]; then - echo "# Reusing $proj $Release-$RC sources" +case $proj in +llvm|openmp) +projsrc=$proj.src +;; +cfe) +projsrc=llvm.src/tools/clang +;; +clang-tools-extra) +projsrc=llvm.src/tools/clang/tools/extra +;; +compiler-rt|libcxx|libcxxabi|libunwind|test-suite) +projsrc=llvm.src/projects/$proj +;; +*) +echo "error: unknown project $proj" +exit 1 +;; +esac + +if [ -d $projsrc ]; then + echo "# Reusing $proj $Release-$RC sources in $projsrc" continue fi -echo "# Exporting $proj $Release-$RC sources" -if ! svn export -q $Base_url/$proj/$ExportBranch $proj.src ; then +echo "# Exporting $proj $Release-$RC sources to $projsrc" +if ! svn export -q $Base_url/$proj/$ExportBranch $projsrc ; then echo "error: failed to export $proj project" exit 1 fi done -echo "# Creating symlinks" -cd $BuildDir/llvm.src/tools -if [ ! -h clang ]; then -ln -s ../../cfe.src clang -fi -cd $BuildDir/cfe.src/tools -if [ ! -h extra ]; then -ln -s ../../clang-tools-extra.src extra -fi -cd $BuildDir/llvm.src/projects -if [ -d $BuildDir/test-suite.src ] && [ ! -h test-suite ]; then -ln -s ../../test-suite.src test-suite -fi -if [ -d $BuildDir/compiler-rt.src ] && [ ! -h compiler-rt ]; then -ln -s ../../compiler-rt.src compiler-rt -fi -if [ -d $BuildDir/libcxx.src ] && [ ! -h libcxx ]; then -ln -s ../../libcxx.src libcxx -fi -if [ -d $BuildDir/libcxxabi.src ] && [ ! -h libcxxabi ]; then -ln -s ../../libcxxabi.src libcxxabi -fi -if [ -d $BuildDir/libunwind.src ] && [ ! -h libunwind ]; then -ln -s ../../libunwind.src libunwind -fi - cd $BuildDir } -Dimitry > On 22 Aug 2015, at 18:54, Dimitry Andric via llvm-dev > wrote: > > The problem seems to be caused by the way the symlinks are setup in > test-release.sh, e.g. like so: > > llvm.src/tools/clang -> ../../cfe.src > cfe.src/tools/extra -> ../../clang-tools-extra.src > > When it then tries to access the path > llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, > it fails. I tried this on both FreeBSD, OSX and Linux, but it fails > everywhere. > > For example, on Linux: > > $ ls -l ~/foo/llvm.src/tools/clang > lrwxrwxrwx 1 dim dim 13 2015-08-22 18:40:16 > /home/dim/foo/llvm.src/tools/clang -> ../../cfe.src/ > $ ls -l ~/foo/cfe.src/tools/extra > lrwxrwxrwx 1 dim dim 27 2015-08-22 18:53:04 /home/dim/foo/cfe.src/tools/extra > -> ../../clang-tools-extra.src/ > $ ls -l > ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling > total 16 > -rw-r--r-- 1 dim dim 8983 2015-08-22 18:17:18 ApplyReplacements.cpp > -rw-r--r-- 1 dim dim 526 2015-08-22 18:17:18 Makefile > $ ls -l > ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include > ls: cannot access > /home/dim/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include: > No such file or directory > > Note that > llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. > goes back to the top level, where *.src is checked out: > > $ ls -l > ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. > total 12 > drwxr-xr-x 16 dim dim 4096 2015-08-22 18:17:16 cfe.src/ > drwxr-xr-x 14 dim dim 4096 2015-08-22 18:40:32 clang-tools-extra.src/ > drwxr-xr-x 16 dim dim 4096 2015-08-22 18:13:58 llvm.src/ > > Of course at a level even below that, there is little chance of an include > directory existing. How does anybody else manage to build using the > test-release.sh script, and having clang-tools-extra? > > -Dimitry > >> On 21 Aug 2015, at 14:09, Dimitry Andric via lldb-dev >> wrote: >> >> Strangely, the clang-tools-extra stuff does build if I manually check it out >> like so (without any symlinks): >> >> .<-- >> https://llvm.org/svn/llvm-project/llvm/branches/release_37 >> tools/clang <-- >> https://llvm.org/svn/llvm-project/cfe/branches/release_37 >> tools/clang/tools/extra <-- >> https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 >> >> I'll investigate, because it would be nice to have those tools. >> >> -Dimitry >> >>> On 21 Aug 2015,
[lldb-dev] [Bug 24548] New: Build fails on unsupported archs for Native Thread
https://llvm.org/bugs/show_bug.cgi?id=24548 Bug ID: 24548 Summary: Build fails on unsupported archs for Native Thread Product: lldb Version: 3.7 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: sylves...@debian.org CC: llvm-b...@lists.llvm.org Classification: Unclassified On s390x, lldb fails to build with: /«BUILDDIR»/llvm-toolchain-3.7-3.7~+rc3/tools/lldb/source/Plugins/Process/Linux/NativeThreadLinux.cpp:167:29: error: 'NativeRegisterContextLinux' has not been declared Full log: https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-3.7&arch=s390x&ver=1%3A3.7~%2Brc3-1&stamp=1440186826 Instead of failure, we should disable the feature on unsupported arch. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
Le 21/08/2015 02:51, Hans Wennborg a écrit : > Hello everyone, > > 3.7-rc3 has just been tagged. Testers, please test, build binaries, > upload to the sftp and report results to this thread. > Uploaded in Debian. Works fine on the major archs However, lldb fails to build on some archs. I reported bug: https://llvm.org/bugs/show_bug.cgi?id=24548 Cheers, Sylvestre ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
Still no complete go, doing the tests on i386 failed with some weird sed error: [...] Making Unit/lit.site.cfg for Clang extra tools... sed: lit.tmp: No such file or directory Makefile:61: recipe for target 'Unit/lit.site.cfg' failed gmake[2]: *** [Unit/lit.site.cfg] Error 1 Strangely enough, this does not happen on amd64. Maybe it is some sort of race condition? Did anybody see this too? Back to the investigation again... :( -Dimitry > On 22 Aug 2015, at 21:23, Dimitry Andric via llvm-dev > wrote: > > It's building with this patch now, already at Phase3, so it seems to work: > > Index: trunk/utils/release/test-release.sh > === > --- trunk/utils/release/test-release.sh (revision 245679) > +++ trunk/utils/release/test-release.sh (working copy) > @@ -266,43 +268,36 @@ > check_valid_urls > > for proj in $projects ; do > -if [ -d $proj.src ]; then > - echo "# Reusing $proj $Release-$RC sources" > +case $proj in > +llvm|openmp) > +projsrc=$proj.src > +;; > +cfe) > +projsrc=llvm.src/tools/clang > +;; > +clang-tools-extra) > +projsrc=llvm.src/tools/clang/tools/extra > +;; > +compiler-rt|libcxx|libcxxabi|libunwind|test-suite) > +projsrc=llvm.src/projects/$proj > +;; > +*) > +echo "error: unknown project $proj" > +exit 1 > +;; > +esac > + > +if [ -d $projsrc ]; then > + echo "# Reusing $proj $Release-$RC sources in $projsrc" > continue > fi > -echo "# Exporting $proj $Release-$RC sources" > -if ! svn export -q $Base_url/$proj/$ExportBranch $proj.src ; then > +echo "# Exporting $proj $Release-$RC sources to $projsrc" > +if ! svn export -q $Base_url/$proj/$ExportBranch $projsrc ; then > echo "error: failed to export $proj project" > exit 1 > fi > done > > -echo "# Creating symlinks" > -cd $BuildDir/llvm.src/tools > -if [ ! -h clang ]; then > -ln -s ../../cfe.src clang > -fi > -cd $BuildDir/cfe.src/tools > -if [ ! -h extra ]; then > -ln -s ../../clang-tools-extra.src extra > -fi > -cd $BuildDir/llvm.src/projects > -if [ -d $BuildDir/test-suite.src ] && [ ! -h test-suite ]; then > -ln -s ../../test-suite.src test-suite > -fi > -if [ -d $BuildDir/compiler-rt.src ] && [ ! -h compiler-rt ]; then > -ln -s ../../compiler-rt.src compiler-rt > -fi > -if [ -d $BuildDir/libcxx.src ] && [ ! -h libcxx ]; then > -ln -s ../../libcxx.src libcxx > -fi > -if [ -d $BuildDir/libcxxabi.src ] && [ ! -h libcxxabi ]; then > -ln -s ../../libcxxabi.src libcxxabi > -fi > -if [ -d $BuildDir/libunwind.src ] && [ ! -h libunwind ]; then > -ln -s ../../libunwind.src libunwind > -fi > - > cd $BuildDir > } > > -Dimitry > >> On 22 Aug 2015, at 18:54, Dimitry Andric via llvm-dev >> wrote: >> >> The problem seems to be caused by the way the symlinks are setup in >> test-release.sh, e.g. like so: >> >> llvm.src/tools/clang -> ../../cfe.src >> cfe.src/tools/extra -> ../../clang-tools-extra.src >> >> When it then tries to access the path >> llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, >> it fails. I tried this on both FreeBSD, OSX and Linux, but it fails >> everywhere. >> >> For example, on Linux: >> >> $ ls -l ~/foo/llvm.src/tools/clang >> lrwxrwxrwx 1 dim dim 13 2015-08-22 18:40:16 >> /home/dim/foo/llvm.src/tools/clang -> ../../cfe.src/ >> $ ls -l ~/foo/cfe.src/tools/extra >> lrwxrwxrwx 1 dim dim 27 2015-08-22 18:53:04 >> /home/dim/foo/cfe.src/tools/extra -> ../../clang-tools-extra.src/ >> $ ls -l >> ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling >> total 16 >> -rw-r--r-- 1 dim dim 8983 2015-08-22 18:17:18 ApplyReplacements.cpp >> -rw-r--r-- 1 dim dim 526 2015-08-22 18:17:18 Makefile >> $ ls -l >> ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include >> ls: cannot access >> /home/dim/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include: >> No such file or directory >> >> Note that >> llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. >> goes back to the top level, where *.src is checked out: >> >> $ ls -l >> ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. >> total 12 >> drwxr-xr-x 16 dim dim 4096 2015-08-22 18:17:16 cfe.src/ >> drwxr-xr-x 14 dim dim 4096 2015-08-22 18:40:32 clang-tools-extra.src/ >> drwxr-xr-x 16 dim dim 4096 2015-08-22 18:13:58 llvm.src/ >> >> Of course at a level even below that, there is little chance of an include >> directory existing. How does anybody el
Re: [lldb-dev] [llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
Right, I found out the problem. It's because clang-tools-extra's test Makefile uses the temporary filename "lit.tmp" for both its main lit.site.cfg, and for Unit/lit.site.cfg. If these make jobs get run simultaneously, one or the other temp file can unexpectedly disappear. The following fixes it, similar to what is done in clang's own test Makefile. Hans, are you OK with me checking this in to clang-tools-extra trunk (not sure who owns that), then merging it to the release_37 branch? Then it is at least fixed for the final build. Index: tools/clang/tools/extra/test/Makefile === --- tools/clang/tools/extra/test/Makefile (revision 245796) +++ tools/clang/tools/extra/test/Makefile (working copy) @@ -60,12 +60,12 @@ Unit/lit.site.cfg: FORCE @echo "Making Unit/lit.site.cfg for Clang extra tools..." @$(MKDIR) $(dir $@) - @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> lit.tmp - @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> lit.tmp - @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> lit.tmp - @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> lit.tmp - @sed -f lit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@ - @-rm -f lit.tmp + @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> unit.tmp + @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> unit.tmp + @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> unit.tmp + @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> unit.tmp + @sed -f unit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@ + @-rm -f unit.tmp clean:: @ find . -name Output | xargs rm -fr -Dimitry > On 23 Aug 2015, at 01:13, Dimitry Andric wrote: > > Still no complete go, doing the tests on i386 failed with some weird sed > error: > > [...] > Making Unit/lit.site.cfg for Clang extra tools... > sed: lit.tmp: No such file or directory > Makefile:61: recipe for target 'Unit/lit.site.cfg' failed > gmake[2]: *** [Unit/lit.site.cfg] Error 1 > > Strangely enough, this does not happen on amd64. Maybe it is some sort of > race condition? Did anybody see this too? > > Back to the investigation again... :( > > -Dimitry > >> On 22 Aug 2015, at 21:23, Dimitry Andric via llvm-dev >> wrote: >> >> It's building with this patch now, already at Phase3, so it seems to work: >> >> Index: trunk/utils/release/test-release.sh >> === >> --- trunk/utils/release/test-release.sh (revision 245679) >> +++ trunk/utils/release/test-release.sh (working copy) >> @@ -266,43 +268,36 @@ >>check_valid_urls >> >>for proj in $projects ; do >> -if [ -d $proj.src ]; then >> - echo "# Reusing $proj $Release-$RC sources" >> +case $proj in >> +llvm|openmp) >> +projsrc=$proj.src >> +;; >> +cfe) >> +projsrc=llvm.src/tools/clang >> +;; >> +clang-tools-extra) >> +projsrc=llvm.src/tools/clang/tools/extra >> +;; >> +compiler-rt|libcxx|libcxxabi|libunwind|test-suite) >> +projsrc=llvm.src/projects/$proj >> +;; >> +*) >> +echo "error: unknown project $proj" >> +exit 1 >> +;; >> +esac >> + >> +if [ -d $projsrc ]; then >> + echo "# Reusing $proj $Release-$RC sources in $projsrc" >> continue >>fi >> -echo "# Exporting $proj $Release-$RC sources" >> -if ! svn export -q $Base_url/$proj/$ExportBranch $proj.src ; then >> +echo "# Exporting $proj $Release-$RC sources to $projsrc" >> +if ! svn export -q $Base_url/$proj/$ExportBranch $projsrc ; then >>echo "error: failed to export $proj project" >>exit 1 >>fi >>done >> >> -echo "# Creating symlinks" >> -cd $BuildDir/llvm.src/tools >> -if [ ! -h clang ]; then >> -ln -s ../../cfe.src clang >> -fi >> -cd $BuildDir/cfe.src/tools >> -if [ ! -h extra ]; then >> -ln -s ../../clang-tools-extra.src extra >> -fi >> -cd $BuildDir/llvm.src/projects >> -if [ -d $BuildDir/test-suite.src ] && [ ! -h test-suite ]; then >> -ln -s ../../test-suite.src test-suite >> -fi >> -if [ -d $BuildDir/compiler-rt.src ] && [ ! -h compiler-rt ]; then >> -ln -s ../../compiler-rt.src compiler-rt >> -fi >> -if [ -d $BuildDir/libcxx.src ] && [ ! -h libcxx ]; then >> -ln -s ../../libcxx.src libcxx >> -fi >> -if [ -d $BuildDir/libcxxabi.src ] && [ ! -h libcxxabi ]; then >> -ln -s ../../libcxxabi.src libcxxabi >> -fi >> -if [ -d $BuildDir/libunwind.src ] && [ ! -h libunwind ]; then >> -ln -s ../../libunwind.src libunwind >> -fi >> - >>cd $BuildDir >> } >> >> -Dimitry >> >>> On 22 Aug 2015, at 18:54,
