[LLVMdev] [RFC] Raise minimum required CMake version to 3.0

Tue Feb 24 21:59:03 PST 2015

Speaking of new versions of CMake and new features that we should use more,
I would really like to see the static library build move to CMake OBJECT
libraries <http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library>

Object libraries were introduced in CMake 2.8.8.  We had a discussion about
this over lunch today, and I believe this conversion should be possible and
provide benefits for every platform.  An object library, if you're not
familiar, is a library which produces no archive, has no link interface,
and you do not link against it with target_link_libraries.  Instead, you
link against it by including it as a *source* in the sources list when
calling add_library(), which causes CMake to change the way it builds the
command line to the linker.  Instead of passing a single archive to the
linker, it instead passes every single object file separately to the linker.

There are a lot of benefits to using object libraries, but the most
poignant benefit I can point to is on Windows, since that's the platform I
know the most about.  **Incremental Linking is disabled with MSVC when you
link against a library file
<https://msdn.microsoft.com/en-us/library/024awkd1.aspx>.**  Thus, if
everything were an object library, our link times would be massively
improved.  Probably an order of magnitude.

Of course, to do this will be a lot of work on the CMake side.  And we will
need to either deal with CMP0051
<http://www.cmake.org/cmake/help/v3.1/policy/CMP0051.html> or disable the
policy.  I actually submitted a patch earlier today to disable this policy
because I needed an object library to solve an actual serious problem, and
an object library was the only way.  But just a warning in case we go down
this path.

On Tue, Feb 24, 2015 at 2:27 PM Chris Bieneman <beanz at apple.com> wrote:

> My list of useful features in newer CMake versions, that I would like to
> see used:
>
> CMake 2.8.10
> * INTERFACE_LIBRARY (we already use this by hacking around the CMake
> version)
>
> CMake 2.8.11
> * Targets can now have dependencies that are arbitrary files instead of
> just link dependencies (
> http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements)
> * target_include_directories command (allows us to cleanup our code)
> * target_compile_definitions command (allows us to cleanup our code)
> * More updates to the Interface library features
>
> CMake 2.8.12
> * New ALIAS targets
> * CMAKE_CONFIGURATION_TYPES variable is defined in multi-config generators
> (we already use this)
> * XCODE_ATTRIBUTE_* might be nice for our Xcode users…
> * cmake_reset_check_state - would be handy for anyone doing development
> against changing target operating systems
>
> CMake 3.0
> * CMAKE_SYSROOT
> * CMAKE_<LANG>_COMPILER_TARGET would be useful for cross-compiling
>
> Aside from this there are lots of fixes and changes around the export()
> and install(EXPORT) commands that should make cross-compiling better.
>
> Like I said, I actually don’t care that much about the move to 2.8.12.2,
> but I care very strongly about us not being tied to the “stable” version of
> <insert Linux distro>, which may or may not update frequently. I’m not
> thrilled about tying ourselves to Ubuntu, but they at least ship LTS
> releases every two years. Debian release cycles are less predictable, and
> WAY more out of date.
>
> -Chris
>
> On Feb 24, 2015, at 12:09 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>
> On Feb 24, 2015, at 11:56 AM, Chris Bieneman <beanz at apple.com> wrote:
>
>
> On Feb 24, 2015, at 11:13 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>
> On Feb 24, 2015, at 9:33 AM, Chris Bieneman <beanz at apple.com> wrote:
>
>
> On Feb 24, 2015, at 8:45 AM, Tobias Grosser <tobias at grosser.es> wrote:
>
> On 09.02.2015 20:12, Chris Bieneman wrote:
>
> It came up on another thread that our current minimum required CMake
> version 2.8.8, has some bugs that cause issues when building with MSVC +
> Ninja, and one potential solution was to raise the minimum required version
> of CMake.
>
> CMake 3.0 is now 6 months old and CMake 3.1 has been released. I would
> like to propose moving our minimum required CMake version to 3.0.
>
> I’ve attached patches to enforce the change in case anyone wants to test
> it out.
>
> Thoughts/comments/concerns/objections?
>
>
> Hi Chris,
>
> this update broke my cmake LLVM+Polly buildbot (to my knowledge most other
> bots use autoconf). I reverted this temporarily to avoid the buildbot noise
> (this comes a little late, as I was traveling the last days).
>
>
> Actually at this point I think most bots are on CMake. The green dragon
> bots are all CMake, Galina and Takumi’s bots are at least partially on
> CMake.
>
>
> The buildbot is based on the latest debian stable (wheezy), which comes
> with cmake 2.8.9. Is 2.8.9 enough to fix the bug?
>
>
> No. The bug requires 2.8.12.1. I really wanted 3.0, but Chandler requested
> 2.8.12.2 because it was the version in the latest Ubuntu LTS.
>
> I’m going to put on my “unpopular opinion” hat for a second. I don’t think
> it is reasonable for us to limit our CMake version to the lowest common
> denominator of all Linux distributions. I really think the Linux developers
> should just do what I do on OS X and build it from source. Building CMake
> is really simple and fast.
>
> This is kinda a bit of a sore point for me because it turns out that our
> CMake goop for cross-compiling is pretty nasty, and there are features in
> CMake 3.x that make it a lot better. Unfortunately using the new features
> while supporting CMake 2.8.x would only make our goop goopier.
>
>
> How does raising from 2.8.9 to 2.8.12.1 helps? It won’t bring the 3.x
> features that you’d like to have.
>
> As I understood it, bumping the version to 2.8.12.1 is motivated by a bug
> related to "MSVC + Ninja” (http://www.cmake.org/Bug/view.php?id=14492 )
>
>
> Raising CMake 2.8.12.x allows us to remove a bunch of crufty hacks to
> support older versions, and it gets some critical bug fixes for Visual
> Studio and Xcode generators (like support for Xcode 5).
>
> There are a lot of features in 2.8.10, 2.8.11 and 2.8.12 that would be
> nice to have too.
>
>
> If this is indeed a bug in CMake that affects one very specific
> platform/configuration, I don’t see this alone as a justification to raise
> the requirement for all the platform.
> It is up to the user of the platform not to use a CMake version that is
> buggy for their platform/configuration.
>
>
> I actually think we should establish a policy for updating the minimum
> required version of CMake similar to how we update minimum required
> compiler versions. That will allow us to take advantage of the fact that
> the CMake team makes rapid progress without carrying a lot of baggage for
> maintaining compatibility of older versions.
>
> For context. CMake 2.8.9 was released in 8/2012, 2.8.12 was released
> 11/2013, 3.0 was released 6/2014, and 3.1 was released 12/2014.
>
> I suspect that supporting 2 releases back (like we do for VS) probably
> isn’t sufficient because that’s only about 6 months, but I think supporting
> back to 2012 is a bit much for CMake because the project is moving really
> quickly.
>
>
> I agree that the same approach should be taken as for the compiler
> version, i.e. cost/benefit analysis.
>
> The commit that was reverted alone does not show significant benefits in
> our CMake configuration files (10 lines removed to handle CMP0022
> basically).
> You are mentioning “a lot of features” that would be nice to have in
> 2.8.10/11/12.
> What are these features and how/when do you plan to take advantage of
> these features?
> If there is no short-term (next 6 months) plan to improve/extend our CMake
> infrastructure with these features, then this change can wait till then.
>
> Thanks,
>
> Mehdi
>
>
> _______________________________________________
> 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/20150225/a5679ecc/attachment.html>