llvm dev - Nov 2015 - metabug tracking blockers for the cmake transition

Jeremy,

At this point the belief is that there are no issues left blocking removing
autoconf. The plan is to remove it after the 3.8 branch. In case you missed the
thread where that was decided it is here
(http://lists.llvm.org/pipermail/llvm-dev/2015-November/092150.html
<http://lists.llvm.org/pipermail/llvm-dev/2015-November/092150.html>).
This discussion has been going on for over a year, so it shouldn’t be a
surprise.

I see the issues you reported, I don’t consider any of them to be blocking
because they can all be worked around. That doesn’t mean I don’t think we should
fix them (because we should), it just means I don’t think they warrant any
changes in our plans to remove autoconf support.

The two main issues you’re being impacted by are 25664 and 25665.

I suspect that you are hitting 25664 because you’re setting
LLVM_ENABLE_SHARED=On, which probably doesn’t do what you think it does. There
was no equivalent of that flag in autoconf. The autoconf —enable-shared option
maps to LLVM_BUILD_LLVM_DYLIB=On in CMake.

For 25665, we will need to add an option to skip generating targets for libcxx’s
library. I can work that up today or tomorrow.

Also, make sure you are setting LLVM_BUILD_EXTERNAL_COMPILER_RT=On. If you don’t
set that you’re not building libclang_rt with the just-built compiler.

If you have other questions please let me know. I can also share our internal
packaging scripts with you off-list if you'd like. I don’t think there is
anything really secret in them, they’re just not useful to the wider LLVM
community so they aren’t in-tree.

-Chris
> On Nov 29, 2015, at 12:56 AM, Anton Korobeynikov via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
>> I don't think this information has all been entered in to bugzilla,
>> but a tracking bug could make sense if it doesn't already exist.
> See PR15732
> 
> -- 
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
> _______________________________________________
> 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/20151129/bf4b739e/attachment.html>

Thanks, Chris.

No, it is certainly not a surprise.  I've known about it for a while but
haven't had time to attempt the transition until Thanksgiving Holiday.  The
last time I attempted the transition was with llvm-3.4; at that time, I was told
that the cmake build system was not supported for darwin.

Thanks for the pointer on LLVM_BUILD_LLVM_DYLIB.  I did notice that
LLVM_ENABLE_SHARED was doing something different, but I think this approach
might be better for clients than what we were doing before, so I kept it.  I
imagine LLVM_BUILD_LLVM_DYLIB will additionally build the umbrella dylib for
compatability.

I agree that the two issues I mentioned earlier are not blockers; there are
simple workarounds for them.

The new port is mostly working on Mavericks and El Capitan (and I assume
Yosemite but have not checked yet).  However, it is still not building on
Leopard, Snow Leopard, Lion, and Mountain Lion due to two different issues (one
which I haven't reported yet).  On Leopard and SL, -std=c++11 isn't
being passed to the compiler (presumibly I can fix that with some manual
setting), and on Lion and Mountain Lion, linking libc++.dylib fails.  I
haven't yet figured out a workaround for the link issue (#25666) but suspect
I just need to hack up the exports file since we end up not installing the built
libc++ anyways.

Sent from my iPhone...
> On Nov 29, 2015, at 12:11, Chris Bieneman <beanz at apple.com> wrote:
> 
> Jeremy,
> 
> At this point the belief is that there are no issues left blocking removing
autoconf. The plan is to remove it after the 3.8 branch. In case you missed the
thread where that was decided it is here
(http://lists.llvm.org/pipermail/llvm-dev/2015-November/092150.html). This
discussion has been going on for over a year, so it shouldn’t be a surprise.
> 
> I see the issues you reported, I don’t consider any of them to be blocking
because they can all be worked around. That doesn’t mean I don’t think we should
fix them (because we should), it just means I don’t think they warrant any
changes in our plans to remove autoconf support.
> 
> The two main issues you’re being impacted by are 25664 and 25665.
> 
> I suspect that you are hitting 25664 because you’re setting
LLVM_ENABLE_SHARED=On, which probably doesn’t do what you think it does. There
was no equivalent of that flag in autoconf. The autoconf —enable-shared option
maps to LLVM_BUILD_LLVM_DYLIB=On in CMake.
> 
> For 25665, we will need to add an option to skip generating targets for
libcxx’s library. I can work that up today or tomorrow.
> 
> Also, make sure you are setting LLVM_BUILD_EXTERNAL_COMPILER_RT=On. If you
don’t set that you’re not building libclang_rt with the just-built compiler.
> 
> If you have other questions please let me know. I can also share our
internal packaging scripts with you off-list if you'd like. I don’t think
there is anything really secret in them, they’re just not useful to the wider
LLVM community so they aren’t in-tree.
> 
> -Chris
> 
>>> On Nov 29, 2015, at 12:56 AM, Anton Korobeynikov via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>> 
>>> I don't think this information has all been entered in to
bugzilla,
>>> but a tracking bug could make sense if it doesn't already
exist.
>> See PR15732
>> 
>> -- 
>> With best regards, Anton Korobeynikov
>> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>> _______________________________________________
>> 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/20151129/01b8b82a/attachment-0001.html>

> On Nov 29, 2015, at 10:58 AM, Jeremy Sequoia <jeremyhu at apple.com>
wrote:
> 
> Thanks, Chris.
> 
> No, it is certainly not a surprise.  I've known about it for a while
but haven't had time to attempt the transition until Thanksgiving Holiday. 
The last time I attempted the transition was with llvm-3.4; at that time, I was
told that the cmake build system was not supported for darwin.
> 
> Thanks for the pointer on LLVM_BUILD_LLVM_DYLIB.  I did notice that
LLVM_ENABLE_SHARED was doing something different, but I think this approach
might be better for clients than what we were doing before, so I kept it.
On Darwin LLVM_ENABLE_SHARED is very much not advisable. Having clang link
against LLVM via dynamic libraries exponentially increases dyld symbol
resolution and results in a 10-20% increase in process launch time. For a basic
clang with arm, aarch64 and x86 support it is an additional 2-3ms. That kind of
performance regression is generally undesirable.

-Chris
>  I imagine LLVM_BUILD_LLVM_DYLIB will additionally build the umbrella dylib
for compatability.
> 
> I agree that the two issues I mentioned earlier are not blockers; there are
simple workarounds for them.
> 
> The new port is mostly working on Mavericks and El Capitan (and I assume
Yosemite but have not checked yet).  However, it is still not building on
Leopard, Snow Leopard, Lion, and Mountain Lion due to two different issues (one
which I haven't reported yet).  On Leopard and SL, -std=c++11 isn't
being passed to the compiler (presumibly I can fix that with some manual
setting), and on Lion and Mountain Lion, linking libc++.dylib fails.  I
haven't yet figured out a workaround for the link issue (#25666) but suspect
I just need to hack up the exports file since we end up not installing the built
libc++ anyways.
> 
> Sent from my iPhone...
> 
> On Nov 29, 2015, at 12:11, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
> 
>> Jeremy,
>> 
>> At this point the belief is that there are no issues left blocking
removing autoconf. The plan is to remove it after the 3.8 branch. In case you
missed the thread where that was decided it is here
(http://lists.llvm.org/pipermail/llvm-dev/2015-November/092150.html
<http://lists.llvm.org/pipermail/llvm-dev/2015-November/092150.html>).
This discussion has been going on for over a year, so it shouldn’t be a
surprise.
>> 
>> I see the issues you reported, I don’t consider any of them to be
blocking because they can all be worked around. That doesn’t mean I don’t think
we should fix them (because we should), it just means I don’t think they warrant
any changes in our plans to remove autoconf support.
>> 
>> The two main issues you’re being impacted by are 25664 and 25665.
>> 
>> I suspect that you are hitting 25664 because you’re setting
LLVM_ENABLE_SHARED=On, which probably doesn’t do what you think it does. There
was no equivalent of that flag in autoconf. The autoconf —enable-shared option
maps to LLVM_BUILD_LLVM_DYLIB=On in CMake.
>> 
>> For 25665, we will need to add an option to skip generating targets for
libcxx’s library. I can work that up today or tomorrow.
>> 
>> Also, make sure you are setting LLVM_BUILD_EXTERNAL_COMPILER_RT=On. If
you don’t set that you’re not building libclang_rt with the just-built compiler.
>> 
>> If you have other questions please let me know. I can also share our
internal packaging scripts with you off-list if you'd like. I don’t think
there is anything really secret in them, they’re just not useful to the wider
LLVM community so they aren’t in-tree.
>> 
>> -Chris
>> 
>>> On Nov 29, 2015, at 12:56 AM, Anton Korobeynikov via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>> 
>>>> I don't think this information has all been entered in to
bugzilla,
>>>> but a tracking bug could make sense if it doesn't already
exist.
>>> See PR15732
>>> 
>>> -- 
>>> With best regards, Anton Korobeynikov
>>> Faculty of Mathematics and Mechanics, Saint Petersburg State
University
>>> _______________________________________________
>>> 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/20151129/4e1ac358/attachment.html>