LLVM Weekly - #98, Nov 16th 2015

LLVM Weekly - #98, Nov 16th 2015

Is there a metabug in bugzilla that is tracking bugs that are blocking transition to using cmake? Or is there some other way that packagers can indicate issues that should be addressed before the autoconf build system is removed?

eg: 19465 – Cmake shared library format on osx

Chris Bieneman has been posting regular updates to the list on the
current status, listing issues viewed as 'blocking'. e.g. the recent
RFC http://lists.llvm.org/pipermail/llvm-dev/2015-November/092150.html
or late October update
[llvm-dev] [RFC] Late October Update: Progress report on CMake build system's ability to replace autoconf.

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.
Responding to the RFC on removing autoconf thread with any outstanding
issues would also be a good idea.

Best,

Alex

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

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

Thanks, Chris.

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