Chris Bieneman
2015-Feb-03 19:08 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties. Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable - There are patches on the bug that we should review, test, and land * Bug 14109 - CMake build for compiler-rt should use just-built clang - Still waiting for patches, I don't think this is a blocker * Bug 15493 - No option to build shared libLLVM-version.so in CMake - Patches out for review http://reviews.llvm.org/D6157 * Bug 18496 - [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH - Unclear if this is still a problem * Bug 18722 - Option to use CMake with libc++ to compile clang - I think this is done by passing -DLLVM_ENABLE_LIBCXX=On * Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions - I believe this is all done. I've never managed to get the import part of this to work, but the export files are generated * Bug 19875 - libraries and executables need different rpaths - Still outstanding, I don't think this is a blocker. * Bug 21560 - Add support to cmake for using installed versions of LLVM and Clang - Takumi commented that this works. * Bug 21561 - Update release scripts to use CMake - Still outstanding and blocking removal of autoconf * Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in compiler_rt - From discussions on llvm-dev and IRC the proper fix for this is a cross-compiling approach for compiler_rt builds, and this is a blocker. * Bug 21568 - Cannot add rpath - It looks like this is not a blocker because it can be done, but is unwieldy. I think this may be made a lot easier with help from the CMake developers. * Bug 21569 - Can't `make install prefix=/tmp/llvm' with CMake. - I think this is a fundamental difference between CMake and autoconf, and people just need to get used to the difference * Bug 21570 - Cannot set default configuration options for CMake - I think you can do this in CMake by creating a toolchain file and passing it in with CMAKE_TOOLCHAIN_FILE Other issues not tracked by bugs: * FreeBSD seemed to have problems with CMake identifying itself as amd64 causing x86_64 tests to fail * Migrating buildbots * CMake builds for libc++? Thoughts? Anything missing? -Chris
Eric Christopher
2015-Feb-03 20:59 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
On Tue Feb 03 2015 at 11:18:07 AM Chris Bieneman <beanz at apple.com> wrote:> So, we’ve had this conversation a few times, and I wanted to coalate a > status report for all the interested parties. > > Here's the outstanding work and my (not necissarily correct) view of the > status and importance of each one: > > * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable > - There are patches on the bug that we should review, test, and land > > * Bug 14109 - CMake build for compiler-rt should use just-built clang > - Still waiting for patches, I don't think this is a blocker > > * Bug 15493 - No option to build shared libLLVM-version.so in CMake > - Patches out for review http://reviews.llvm.org/D6157 > > * Bug 18496 - [cmake] .S assembly files not compiled by cmake in > libclang_rt.ARCH > - Unclear if this is still a problem > > * Bug 18722 - Option to use CMake with libc++ to compile clang > - I think this is done by passing -DLLVM_ENABLE_LIBCXX=On > > * Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions > - I believe this is all done. I've never managed to get the import part > of this to work, but the export files are generated > > * Bug 19875 - libraries and executables need different rpaths > - Still outstanding, I don't think this is a blocker. > > * Bug 21560 - Add support to cmake for using installed versions of LLVM > and Clang > - Takumi commented that this works. > > * Bug 21561 - Update release scripts to use CMake > - Still outstanding and blocking removal of autoconf > > * Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in > compiler_rt > - From discussions on llvm-dev and IRC the proper fix for this is a > cross-compiling approach for compiler_rt builds, and this is a blocker. > > * Bug 21568 - Cannot add rpath > - It looks like this is not a blocker because it can be done, but is > unwieldy. I think this may be made a lot easier with help from the CMake > developers. > > * Bug 21569 - Can't `make install prefix=/tmp/llvm' with CMake. > - I think this is a fundamental difference between CMake and autoconf, > and people just need to get used to the difference > > * Bug 21570 - Cannot set default configuration options for CMake > - I think you can do this in CMake by creating a toolchain file and > passing it in with CMAKE_TOOLCHAIN_FILE > > > Other issues not tracked by bugs: > > * FreeBSD seemed to have problems with CMake identifying itself as amd64 > causing x86_64 tests to fail > * Migrating buildbots > * CMake builds for libc++? > > > Thoughts? Anything missing? > >Thanks for the update Chris, one thing missing would be a quick cheat sheet transition guide for users etc to do "the things that they used to do". Mostly something for the website under the developer documentation etc. -eric> -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150203/2cb57940/attachment.html>
Jonathan Roelofs
2015-Feb-03 21:06 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
On 2/3/15 12:08 PM, Chris Bieneman wrote:> Other issues not tracked by bugs: > > * CMake builds for libc++?Can you elaborate... what do you mean by this? AFAIK this already works. Jon -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
Renato Golin
2015-Feb-03 21:24 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
On 3 February 2015 at 19:08, Chris Bieneman <beanz at apple.com> wrote:> * Migrating buildbotsMost ARM/AArch64 bots are now running CMake. Only the test-suite is not, but this is on my todo list for this month. There are changes in progress to make it work on Windows, so there should be no reason why it won't work with other arches / OSs.> * CMake builds for libc++?libc++ already works with CMake, though I'm going to add it to the CMake ClangBuilder, so that we can run it inside the build and test-suite, but that's after merging LNT into the ClangBuilder. Since it already works with CMake on its own, I think it's a lower priority. cheers, --renato
Chris Bieneman
2015-Feb-03 21:26 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
> On Feb 3, 2015, at 1:06 PM, Jonathan Roelofs <jroelofs.lists at gmail.com> wrote: > > > > On 2/3/15 12:08 PM, Chris Bieneman wrote: > >> Other issues not tracked by bugs: >> >> * CMake builds for libc++? > Can you elaborate... what do you mean by this? AFAIK this already works.Duncan made a comment on IRC about being libc++, but I’m not aware of what the specific issues were (hence the ?). -Chris> > > Jon > > -- > Jon Roelofs > jonathan at codesourcery.com > CodeSourcery / Mentor Embedded
Hans Wennborg
2015-Feb-05 19:11 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
On Tue, Feb 3, 2015 at 11:08 AM, Chris Bieneman <beanz at apple.com> wrote:> Other issues not tracked by bugs: > > * FreeBSD seemed to have problems with CMake identifying itself as amd64 causing x86_64 tests to fail > * Migrating buildbots > * CMake builds for libc++? > > > Thoughts? Anything missing?We'll need to update the script used for building releases (utils/release/test-release.sh) to use CMake. Once this is done, we can switch the release to CMake, which would be a nice milestone :-) - Hans
Chris Bieneman
2015-Feb-05 19:22 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
I believe that was on my list as "Bug 21561 - Update release scripts to use CMake” -Chris> On Feb 5, 2015, at 11:11 AM, Hans Wennborg <hans at chromium.org> wrote: > > On Tue, Feb 3, 2015 at 11:08 AM, Chris Bieneman <beanz at apple.com> wrote: >> Other issues not tracked by bugs: >> >> * FreeBSD seemed to have problems with CMake identifying itself as amd64 causing x86_64 tests to fail >> * Migrating buildbots >> * CMake builds for libc++? >> >> >> Thoughts? Anything missing? > > We'll need to update the script used for building releases > (utils/release/test-release.sh) to use CMake. Once this is done, we > can switch the release to CMake, which would be a nice milestone :-) > > - Hans
Jonathan Roelofs
2015-Feb-05 19:47 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
On 2/3/15 12:08 PM, Chris Bieneman wrote:> Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: > > * Bug 14109 - CMake build for compiler-rt should use just-built clang > - Still waiting for patches, I don't think this is a blocker >We consider this one a blocker. We shouldn't be assuming that we have available a compiler capable of doing build->target or host->target, other than the host->target one that is the just-built clang. I've heard discussions in the past about this restriction of cmake, but I don't remember the details. Is this something where we could up the minimum required version of cmake to get features we'd need to use in the CMakeLists.txt's? Is there a way to work around it? Having a bootstrap flag for the cmake configure would make it less of a blocker, though I'd still prefer not to have to boostrap every build. IIRC, Chandler has some notes on the right way to pull that off. Cheers, Jon> > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
Jonathan Roelofs
2015-Feb-14 01:35 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
+alexey On 2/5/15 12:47 PM, Jonathan Roelofs wrote:> > > On 2/3/15 12:08 PM, Chris Bieneman wrote: >> Here's the outstanding work and my (not necissarily correct) view of >> the status and importance of each one: >> >> * Bug 14109 - CMake build for compiler-rt should use just-built clang >> - Still waiting for patches, I don't think this is a blockerI Just discovered LLVM_BUILD_EXTERNAL_COMPILER_RT implemented by Alexey in https://www.mail-archive.com/cfe-commits at cs.uiuc.edu/msg91501.html This causes compiler-rt to be built with the just-built clang. For my purposes, this unblocks dropping autoconf (aside from some internal hassles with getting cmake built, but that's on me to deal with). I think it would be better if we built that way by default. What blocks flipping the switch so that the "build with the host compiler" behavior becomes opt-in? I see a note that this flag blocks using the Ninja generator: http://www.cmake.org/Bug/view.php?id=14771 Can that be worked around? Is there anything else? Cheers, Jon -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
Zachary Turner
2015-Feb-16 09:03 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
+Ed Maste, who maintains FreeBSD's LLDB and probably does not check this very often. I know (or at least am pretty sure) that they are using autoconf over there, so he may be aware of other issues. On Tue Feb 03 2015 at 11:19:22 AM Chris Bieneman <beanz at apple.com> wrote:> So, we’ve had this conversation a few times, and I wanted to coalate a > status report for all the interested parties. > > Here's the outstanding work and my (not necissarily correct) view of the > status and importance of each one: > > * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable > - There are patches on the bug that we should review, test, and land > > * Bug 14109 - CMake build for compiler-rt should use just-built clang > - Still waiting for patches, I don't think this is a blocker > > * Bug 15493 - No option to build shared libLLVM-version.so in CMake > - Patches out for review http://reviews.llvm.org/D6157 > > * Bug 18496 - [cmake] .S assembly files not compiled by cmake in > libclang_rt.ARCH > - Unclear if this is still a problem > > * Bug 18722 - Option to use CMake with libc++ to compile clang > - I think this is done by passing -DLLVM_ENABLE_LIBCXX=On > > * Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions > - I believe this is all done. I've never managed to get the import part > of this to work, but the export files are generated > > * Bug 19875 - libraries and executables need different rpaths > - Still outstanding, I don't think this is a blocker. > > * Bug 21560 - Add support to cmake for using installed versions of LLVM > and Clang > - Takumi commented that this works. > > * Bug 21561 - Update release scripts to use CMake > - Still outstanding and blocking removal of autoconf > > * Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in > compiler_rt > - From discussions on llvm-dev and IRC the proper fix for this is a > cross-compiling approach for compiler_rt builds, and this is a blocker. > > * Bug 21568 - Cannot add rpath > - It looks like this is not a blocker because it can be done, but is > unwieldy. I think this may be made a lot easier with help from the CMake > developers. > > * Bug 21569 - Can't `make install prefix=/tmp/llvm' with CMake. > - I think this is a fundamental difference between CMake and autoconf, > and people just need to get used to the difference > > * Bug 21570 - Cannot set default configuration options for CMake > - I think you can do this in CMake by creating a toolchain file and > passing it in with CMAKE_TOOLCHAIN_FILE > > > Other issues not tracked by bugs: > > * FreeBSD seemed to have problems with CMake identifying itself as amd64 > causing x86_64 tests to fail > * Migrating buildbots > * CMake builds for libc++? > > > Thoughts? Anything missing? > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/0f788161/attachment.html>
Chris Bieneman
2015-Feb-16 19:32 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
Ed, Just to be clarify the timeline for this is somewhere between 6 months and never. Don’t look at this as impending, but also don’t ignore it. We have a sizable list of outstanding issues, and some of them are quite substantial (like compiler-rt). Without a concerted effort from the community this is unlikely to happen. -Chris> On Feb 16, 2015, at 1:03 AM, Zachary Turner <zturner at google.com> wrote: > > +Ed Maste, who maintains FreeBSD's LLDB and probably does not check this very often. I know (or at least am pretty sure) that they are using autoconf over there, so he may be aware of other issues. > > On Tue Feb 03 2015 at 11:19:22 AM Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties. > > Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: > > * Bug 12157 - llvmconfig.cmake.in <http://llvmconfig.cmake.in/> make cmake installations not relocatable > - There are patches on the bug that we should review, test, and land > > * Bug 14109 - CMake build for compiler-rt should use just-built clang > - Still waiting for patches, I don't think this is a blocker > > * Bug 15493 - No option to build shared libLLVM-version.so in CMake > - Patches out for review http://reviews.llvm.org/D6157 <http://reviews.llvm.org/D6157> > > * Bug 18496 - [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH > - Unclear if this is still a problem > > * Bug 18722 - Option to use CMake with libc++ to compile clang > - I think this is done by passing -DLLVM_ENABLE_LIBCXX=On > > * Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions > - I believe this is all done. I've never managed to get the import part of this to work, but the export files are generated > > * Bug 19875 - libraries and executables need different rpaths > - Still outstanding, I don't think this is a blocker. > > * Bug 21560 - Add support to cmake for using installed versions of LLVM and Clang > - Takumi commented that this works. > > * Bug 21561 - Update release scripts to use CMake > - Still outstanding and blocking removal of autoconf > > * Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk <http://clang_darwin.mk/> in compiler_rt > - From discussions on llvm-dev and IRC the proper fix for this is a cross-compiling approach for compiler_rt builds, and this is a blocker. > > * Bug 21568 - Cannot add rpath > - It looks like this is not a blocker because it can be done, but is unwieldy. I think this may be made a lot easier with help from the CMake developers. > > * Bug 21569 - Can't `make install prefix=/tmp/llvm' with CMake. > - I think this is a fundamental difference between CMake and autoconf, and people just need to get used to the difference > > * Bug 21570 - Cannot set default configuration options for CMake > - I think you can do this in CMake by creating a toolchain file and passing it in with CMAKE_TOOLCHAIN_FILE > > > Other issues not tracked by bugs: > > * FreeBSD seemed to have problems with CMake identifying itself as amd64 causing x86_64 tests to fail > * Migrating buildbots > * CMake builds for libc++? > > > Thoughts? Anything missing? > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/92cceeaa/attachment.html>
Ed Maste
2015-Feb-17 17:14 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
On 16 February 2015 at 04:03, Zachary Turner <zturner at google.com> wrote:> +Ed Maste, who maintains FreeBSD's LLDB and probably does not check this > very often. I know (or at least am pretty sure) that they are using > autoconf over there, so he may be aware of other issues.We generally don't use the autoconf build here. All of my development against the upstream repository is done with cmake+ninja. We also have a copy of LLVM+Clang+LLDB in the FreeBSD base system. That one uses yet another build system - a set of bespoke BSD make Makefiles. For example, liblldb's Makefile is here: https://svnweb.freebsd.org/base/head/lib/clang/liblldb/Makefile In the case of LLDB I created these mainly by using sed on the CMakeLists.txt files. It looks like the FreeBSD LLDB buildbot is using autoconf, but that should be easily changed.
Joerg Sonnenberger
2015-Feb-17 20:21 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
On Mon, Feb 16, 2015 at 09:03:11AM +0000, Zachary Turner wrote:> +Ed Maste, who maintains FreeBSD's LLDB and probably does not check this > very often. I know (or at least am pretty sure) that they are using > autoconf over there, so he may be aware of other issues.Just for the record, as far as NetBSD is concerned, LLDB without autoconf is a non-issue. autoconf is only relevant for the bootstrapping, so code outside llvm, clang and maybe lld is perfectly acceptable as cmake-only. Joerg
Alexey Samsonov
2015-Feb-17 22:01 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
On Tue, Feb 3, 2015 at 11:08 AM, Chris Bieneman <beanz at apple.com> wrote:> So, we’ve had this conversation a few times, and I wanted to coalate a > status report for all the interested parties. > > Here's the outstanding work and my (not necissarily correct) view of the > status and importance of each one: > > * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable > - There are patches on the bug that we should review, test, and land > > * Bug 14109 - CMake build for compiler-rt should use just-built clang > - Still waiting for patches, I don't think this is a blocker > > * Bug 15493 - No option to build shared libLLVM-version.so in CMake > - Patches out for review http://reviews.llvm.org/D6157 > > * Bug 18496 - [cmake] .S assembly files not compiled by cmake in > libclang_rt.ARCH > - Unclear if this is still a problem > > * Bug 18722 - Option to use CMake with libc++ to compile clang > - I think this is done by passing -DLLVM_ENABLE_LIBCXX=On > > * Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions > - I believe this is all done. I've never managed to get the import part > of this to work, but the export files are generated > > * Bug 19875 - libraries and executables need different rpaths > - Still outstanding, I don't think this is a blocker. > > * Bug 21560 - Add support to cmake for using installed versions of LLVM > and Clang > - Takumi commented that this works. > > * Bug 21561 - Update release scripts to use CMake > - Still outstanding and blocking removal of autoconf > > * Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in > compiler_rt > - From discussions on llvm-dev and IRC the proper fix for this is a > cross-compiling approach for compiler_rt builds, and this is a blocker. > > * Bug 21568 - Cannot add rpath > - It looks like this is not a blocker because it can be done, but is > unwieldy. I think this may be made a lot easier with help from the CMake > developers. > > * Bug 21569 - Can't `make install prefix=/tmp/llvm' with CMake. > - I think this is a fundamental difference between CMake and autoconf, > and people just need to get used to the difference > > * Bug 21570 - Cannot set default configuration options for CMake > - I think you can do this in CMake by creating a toolchain file and > passing it in with CMAKE_TOOLCHAIN_FILE > > > Other issues not tracked by bugs: > > * FreeBSD seemed to have problems with CMake identifying itself as amd64 > causing x86_64 tests to fail > * Migrating buildbots > * CMake builds for libc++? > > > Thoughts? Anything missing? >One more thing: we should probably update "Getting Started" pages ( http://clang.llvm.org/get_started.html, http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary) to refer to CMake as the "recommended" way to build LLVM, and to autotools as "works for now".> > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Alexey Samsonov vonosmas at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/9114531d/attachment.html>
Eric Christopher
2015-Feb-17 22:33 UTC
[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
Seems reasonable. -eric On Tue Feb 17 2015 at 2:23:46 PM Alexey Samsonov <vonosmas at gmail.com> wrote:> On Tue, Feb 3, 2015 at 11:08 AM, Chris Bieneman <beanz at apple.com> wrote: > >> So, we’ve had this conversation a few times, and I wanted to coalate a >> status report for all the interested parties. >> >> Here's the outstanding work and my (not necissarily correct) view of the >> status and importance of each one: >> >> * Bug 12157 - llvmconfig.cmake.in make cmake installations not >> relocatable >> - There are patches on the bug that we should review, test, and land >> >> * Bug 14109 - CMake build for compiler-rt should use just-built clang >> - Still waiting for patches, I don't think this is a blocker >> >> * Bug 15493 - No option to build shared libLLVM-version.so in CMake >> - Patches out for review http://reviews.llvm.org/D6157 >> >> * Bug 18496 - [cmake] .S assembly files not compiled by cmake in >> libclang_rt.ARCH >> - Unclear if this is still a problem >> >> * Bug 18722 - Option to use CMake with libc++ to compile clang >> - I think this is done by passing -DLLVM_ENABLE_LIBCXX=On >> >> * Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions >> - I believe this is all done. I've never managed to get the import part >> of this to work, but the export files are generated >> >> * Bug 19875 - libraries and executables need different rpaths >> - Still outstanding, I don't think this is a blocker. >> >> * Bug 21560 - Add support to cmake for using installed versions of LLVM >> and Clang >> - Takumi commented that this works. >> >> * Bug 21561 - Update release scripts to use CMake >> - Still outstanding and blocking removal of autoconf >> >> * Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk >> in compiler_rt >> - From discussions on llvm-dev and IRC the proper fix for this is a >> cross-compiling approach for compiler_rt builds, and this is a blocker. >> >> * Bug 21568 - Cannot add rpath >> - It looks like this is not a blocker because it can be done, but is >> unwieldy. I think this may be made a lot easier with help from the CMake >> developers. >> >> * Bug 21569 - Can't `make install prefix=/tmp/llvm' with CMake. >> - I think this is a fundamental difference between CMake and autoconf, >> and people just need to get used to the difference >> >> * Bug 21570 - Cannot set default configuration options for CMake >> - I think you can do this in CMake by creating a toolchain file and >> passing it in with CMAKE_TOOLCHAIN_FILE >> >> >> Other issues not tracked by bugs: >> >> * FreeBSD seemed to have problems with CMake identifying itself as amd64 >> causing x86_64 tests to fail >> * Migrating buildbots >> * CMake builds for libc++? >> >> >> Thoughts? Anything missing? >> > > One more thing: we should probably update "Getting Started" pages ( > http://clang.llvm.org/get_started.html, > http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary) > to > refer to CMake as the "recommended" way to build LLVM, and to autotools as > "works for now". > > >> >> -Chris >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > > -- > Alexey Samsonov > vonosmas at gmail.com > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/cfcdf2a5/attachment.html>