llvm dev - Oct 2015 - [RFC] Late October Update: Progress report on CMake build system's ability to replace autoconf

Hi LLVMDev,

There’s been a good bit of progress this month, and with the dev meeting later
this week I thought I’d send out a second update. There are only two outstanding
blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I
would greatly appreciate if someone who works on Mips would take a look at PR
23947.

The following issues have been marked as fixed since the last update I sent out.
* Bug 14109 - CMake build for compiler-rt should use just-built clang
* Bug 24157 - CMake built shared library does not export all public symbols

These issues are still outstanding. Classification of blocking vs non-blocking
are my own opinions, please let me know if you disagree. All non-blocking issues
are still serious bugs that need to be fixed.

Blocking Issues:
* Bug 14200 - -fno-rtti not in cxxflags given by llvm-config (Patches out for
review http://reviews.llvm.org/D11849 <http://reviews.llvm.org/D11849>)
* Bug 21568 - Cannot add rpath
* Bug 23947 - CMake+Mips: find_library() doesn't work correctly when
recursing 64-bit (both N32 and N64 ABI's) compiler on Debian Jessie
* Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible
with ldconfig (Two conflicting approaches are proposed to fix this in
http://reviews.llvm.org/D13841 <http://reviews.llvm.org/D13841> &
http://reviews.llvm.org/D14040 <http://reviews.llvm.org/D14040>)

Non-Blocking Issues:
* Bug 19875 - libraries and executables need different rpaths
* Bug 22466 - cmake build should provide way to run tablegen with no arguments
* Bug 23746 - test-suite lacks CMake support (Part 1 landed r251431, Part 2 
approved patches http://reviews.llvm.org/D14061)
* Bug 24919 - [autoconf -> cmake] libclang.a is not packaged in the Ubuntu
x86_64 pre-built

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
* We need to make sure libc++ works properly on Darwin
* Put together a “cheat sheet” document for transitioning

Thank you everyone who has helped out to get us this far. We're getting
awfully close now!

Thanks,
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151027/0bf8e115/attachment.html>

Chris Bieneman via llvm-dev wrote:
> * FreeBSD seemed to have problems with CMake identifying itself as amd64
> causing x86_64 tests to fail
This seems interesting. Do you have any more information?

Thanks,

Steve.

Chris Bieneman via llvm-dev wrote:
> Thank you everyone who has helped out to get us this far. We're getting
> awfully close now!
Thanks for all of your efforts and for owning this!

On 10/27/15 2:17 PM, Chris Bieneman via llvm-dev wrote:
> Hi LLVMDev,
>
> There’s been a good bit of progress this month, and with the dev meeting
> later this week I thought I’d send out a second update. There are only
> two outstanding blocking issues that don’t have patches proposed,
> PR 21568 & PR 23947. I would greatly appreciate if someone who works on
> Mips would take a look at PR 23947.
>
> The following issues have been marked as fixed since the last update I
> sent out.
> * Bug 14109 - CMake build for compiler-rt should use just-built clang
> * Bug 24157 - CMake built shared library does not export all public symbols
>
> These issues are still outstanding. Classification of blocking vs
> non-blocking are my own opinions, please let me know if you disagree.
> All non-blocking issues are still serious bugs that need to be fixed.
>
> Blocking Issues:
> * Bug 21568 - Cannot add rpath
I don't think this ^ one is a blocker. Reid gives a suitable workaround 
in the bug ticket.


Jon
> * Bug 23947 - CMake+Mips: find_library() doesn't work correctly when
> recursing 64-bit (both N32 and N64 ABI's) compiler on Debian Jessie
> * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not
> compatible with ldconfig (Two conflicting approaches are proposed to fix
> this in http://reviews.llvm.org/D13841 &
http://reviews.llvm.org/D14040)
>
> Non-Blocking Issues:
> * Bug 19875 - libraries and executables need different rpaths
> * Bug 22466 - cmake build should provide way to run tablegen with no
> arguments
> * Bug 23746 - test-suite lacks CMake support (Part 1 landed r251431,
> Part 2  approved patches http://reviews.llvm.org/D14061)
> * Bug 24919 - [autoconf -> cmake] libclang.a is not packaged in the
> Ubuntu x86_64 pre-built
>
> 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
> * We need to make sure libc++ works properly on Darwin
> * Put together a “cheat sheet” document for transitioning
>
> Thank you everyone who has helped out to get us this far. We're getting
> awfully close now!
>
> Thanks,
> -Chris
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

> On Oct 27, 2015, at 1:35 PM, Stephen Kelly via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Chris Bieneman via llvm-dev wrote:
> 
>> * FreeBSD seemed to have problems with CMake identifying itself as
amd64
>> causing x86_64 tests to fail
> 
> This seems interesting. Do you have any more information?
This came from an old thread:
http://lists.llvm.org/pipermail/llvm-dev/2014-October/078363.html
<http://lists.llvm.org/pipermail/llvm-dev/2014-October/078363.html>

I don’t have any context more than what was there.

-Chris
> 
> Thanks,
> 
> Steve.
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151027/73d5d1fe/attachment.html>

On Wed, 28 Oct 2015 at 04:17 Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi LLVMDev,
>
> There’s been a good bit of progress this month, and with the dev meeting
> later this week I thought I’d send out a second update. There are only two
> outstanding blocking issues that don’t have patches proposed, PR 21568
&
> PR 23947. I would greatly appreciate if someone who works on Mips would
> take a look at PR 23947.
>
> The following issues have been marked as fixed since the last update I
> sent out.
> * Bug 14109 - CMake build for compiler-rt should use just-built clang
> * Bug 24157 - CMake built shared library does not export all public symbols
>
> These issues are still outstanding. Classification of blocking vs
> non-blocking are my own opinions, please let me know if you disagree. All
> non-blocking issues are still serious bugs that need to be fixed.
>
> Blocking Issues:
> * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config (Patches out
> for review http://reviews.llvm.org/D11849)
> * Bug 21568 - Cannot add rpath
> * Bug 23947 - CMake+Mips: find_library() doesn't work correctly when
> recursing 64-bit (both N32 and N64 ABI's) compiler on Debian Jessie
> * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not
> compatible with ldconfig (Two conflicting approaches are proposed to fix
> this in http://reviews.llvm.org/D13841 &
http://reviews.llvm.org/D14040)
>
Sorry Chris, I had not seen your proposal. A little more background on why
I implemented such a complicated approach.

Debian's current packaging tacks a ".1" on the end of the SONAME.
I *think*
this is necessary, but I'm not a Debian packaging expert; Sylvestre could
confirm. Anyway, that .1 doesn't make sense for everyone (anyone else?),
which is why it would be specified in an option.

> Non-Blocking Issues:
> * Bug 19875 - libraries and executables need different rpaths
> * Bug 22466 - cmake build should provide way to run tablegen with no
> arguments
> * Bug 23746 - test-suite lacks CMake support (Part 1 landed r251431, Part
> 2  approved patches http://reviews.llvm.org/D14061)
> * Bug 24919 - [autoconf -> cmake] libclang.a is not packaged in the
Ubuntu
> x86_64 pre-built
>
> 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
> * We need to make sure libc++ works properly on Darwin
> * Put together a “cheat sheet” document for transitioning
>
> Thank you everyone who has helped out to get us this far. We're getting
> awfully close now!
>
> Thanks,
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151027/12aff637/attachment.html>

> On Oct 27, 2015, at 4:10 PM, Andrew Wilkins <axwalk at gmail.com>
wrote:
> 
> On Wed, 28 Oct 2015 at 04:17 Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi LLVMDev,
> 
> There’s been a good bit of progress this month, and with the dev meeting
later this week I thought I’d send out a second update. There are only two
outstanding blocking issues that don’t have patches proposed, PR 21568 & PR
23947. I would greatly appreciate if someone who works on Mips would take a look
at PR 23947.
> 
> The following issues have been marked as fixed since the last update I sent
out.
> * Bug 14109 - CMake build for compiler-rt should use just-built clang
> * Bug 24157 - CMake built shared library does not export all public symbols
> 
> These issues are still outstanding. Classification of blocking vs
non-blocking are my own opinions, please let me know if you disagree. All
non-blocking issues are still serious bugs that need to be fixed.
> 
> Blocking Issues:
> * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config (Patches out
for review http://reviews.llvm.org/D11849
<http://reviews.llvm.org/D11849>)
> * Bug 21568 - Cannot add rpath
> * Bug 23947 - CMake+Mips: find_library() doesn't work correctly when
recursing 64-bit (both N32 and N64 ABI's) compiler on Debian Jessie
> * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not
compatible with ldconfig (Two conflicting approaches are proposed to fix this in
http://reviews.llvm.org/D13841 <http://reviews.llvm.org/D13841> &
http://reviews.llvm.org/D14040 <http://reviews.llvm.org/D14040>)
> 
> Sorry Chris, I had not seen your proposal. A little more background on why
I implemented such a complicated approach.
> 
> Debian's current packaging tacks a ".1" on the end of the
SONAME. I *think* this is necessary, but I'm not a Debian packaging expert;
Sylvestre could confirm. Anyway, that .1 doesn't make sense for everyone
(anyone else?), which is why it would be specified in an option.
Your patch and mine do very different things, and I’m not very picky about how
this gets handled because I mostly care about Darwin. My patch reworks
construction of the output file names so that they match autoconf
(libLLVM-3.8.0svn.so as opposed to libLLVM.so.3.8.0svn). Your patches make the
versions and library name configurable. Not sure if they both meet the same
need.

I’m not really picky about how the problem is solved as long as it is solved.

-Chris
>  
> Non-Blocking Issues:
> * Bug 19875 - libraries and executables need different rpaths
> * Bug 22466 - cmake build should provide way to run tablegen with no
arguments
> * Bug 23746 - test-suite lacks CMake support (Part 1 landed r251431, Part 2
approved patches http://reviews.llvm.org/D14061
<http://reviews.llvm.org/D14061>)
> * Bug 24919 - [autoconf -> cmake] libclang.a is not packaged in the
Ubuntu x86_64 pre-built
> 
> 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
> * We need to make sure libc++ works properly on Darwin
> * Put together a “cheat sheet” document for transitioning
> 
> Thank you everyone who has helped out to get us this far. We're getting
awfully close now!
> 
> Thanks,
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151027/678d5849/attachment.html>