llvm dev - Feb 2015 - [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

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>

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

On 3 February 2015 at 19:08, Chris Bieneman <beanz at apple.com>
wrote:
> * Migrating buildbots
Most 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

> 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

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

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

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

+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 blocker
I 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

+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>

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>

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.

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

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>

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>