llvm dev - Apr 2016 - [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3

Most of the comments I have are actually very well captured by Chandler's
email, so I'm not going to pile on. I do have a few things to add.

Renato, in your most recent email you comment about differentiating *stable* vs
random versions of CMake built from source. I believe as a community our
recommendation should be that people download CMake sources from
https://CMake.org/download/ instead of git. Then they get the source of a known
stable release. If people choose to pull random git hashes or tags, that is
their decision, but since the minimum version I'm proposing is widely
available I think it will be uncommon.

So let's talk about ExternalProject.

Is it the only way? No. There are actually several approaches that could be
taken here, but let me explain why I want to do it this way.

At a very basic level there are really two high-level approaches to solve the
problem of building runtime libraries multiple times:

(1) Do the "Darwin" thing hand hack building multiple targets from the
same CMake configuration.
(2) Configure the runtimes multiple times, once per target.

I've been working to try and un-do the horrible Darwin approach we have
because I think it has some serious problems, but an alternative solution would
be to extend the Darwin approach to every other platform. If you do this you
don't need ExternalProject, but you do need to do some really dirty hacks.
If you want to understand those hacks, just look at CompilerRTDarwinUtils.cmake
in compiler-rt. That is a bit of evil that I’m responsible for, and I’ll be
paying down that debt for a long time to come.

Apart from this we also have another problem. The build system makes
configuration decisions based on the compiler *at configuration time*. The
problem is you really want to configure compiler-rt (and the other runtimes)
*after* you've already built clang so the runtimes are configured and built
with the clang you just built. The only way to do that is with some mechanism
similar to ExternalProject.

We could roll our own. At this point I'm going to put on my
"non-constructive reality" hat. I'm not going to do that. I
don't mean that from a philosophical stance; I love reinventing me some
wheels. I mean that from a "there is no way my boss is going to let me
waste that much of my time solving an already solved problem" stance. Even
using ExternalProject, this work is largely a side-project of mine, so it is
going to take me a while to untangle it.

Replicating ExternalProject would be a lot of work, and it would be a huge
maintenance burden to the community. As a data point, the one place in LLVM
where we don't use ExternalProject (and we should be) is the cross-compiling
goop, and it is a gigantic mess (see: CrossCompile.cmake and every mention of
LLVM_NATIVE_BUILD in TableGen.cmake). It is filled with bugs and in desperate
need of disentangling. This is another one of my sins that I need to repent.

I feel I should also point out that ExternalProject isn't a silver bullet.
It isn't going to solve all our problems, and since it is one of the more
actively changing parts of CMake we may find ourselves re-visiting this
conversation in a year or two talking about a newer version of CMake.

-Chris

> On Apr 27, 2016, at 9:13 AM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> On 27 April 2016 at 16:29, Chandler Carruth <chandlerc at google.com>
wrote:
>> The folks working on our build infrastructure have limited time. Making
them
>> cope with designing the usage of CMake in such a way that it gracefully
>> degrades across many major versions of CMake makes their work
substantially
>> harder, and even if it is theoretically possible to do, it may become
>> sufficiently annoying or slow to do that we simply don't get
improvements to
>> how we build things.
> 
> I agree, this is one of the strong points towards the move. Much more
> relevant than both personal preferences.
> 
> 
>> I'm not really sure how pushing towards newer released and stable
versions
>> will cause *more* of a patchwork of versions than following the distro
>> installed versions. It seems to involve strictly fewer versions of
CMake.
>> But maybe I'm not understanding your concern here?
> 
> I may digress a little, so bear with me. But just to be sure, I want
> you to know that I don't disagree with the upgrade, I just want to
> make the reasons clear.
> 
> Today, installing CMake (or any dep) from packages means they were
> validated and released by people that did the validation.
> 
> Right now, I *need* CMake 3.x and Ninja 1.5.* (because of LINK_POOL),
> and I have no access on my ageing boards to install them from
> packages. so I have gone to the trouble to download a *stable* copy of
> the sources, and built from source.
> 
> This, however, adds to the maintenance of adding new boards, or
> putting them back online when they fail. Work done at those times is
> stressful, because we're out of coverage until I can put them back in
> production. It's not a lot of work, but it's a very stressful one.
But
> I'm willing to consciously pay the price and I do so with great care.
> 
> But asking people to build CMake encourages them to build whatever
> stable, or even unstable versions of CMake. Not that they can't do it
> today, but being this the recommended way means people will think less
> about that step and just get whatever is easier. That's where unknown
> bugs in unstable versions will catch us, because no one will know it's
> an unstable CMake version on a buildbot until a lot of time has been
> wasted.
> 
> I agree, however, that this is not a very strong argument. But it's
> stronger than personal preference. That's why I was asking for the
> real reasons.
> 
> 
>> - Most major Linux distros have support out of the box in their
"current"
>> version (OpenSUSE, Fedora, Ubuntu, Debian, Arch), and several in a
released
>> version (Ubuntu, Debian, Arch).
> 
> Note that this is *current* and mostly x86_64. Life on ARM, MIPS and
> probably PPC is not as shiny.
> 
> At least on ARM, different boards may have different (old) systems
> that they were validated with and will *not* upgrade, at least not
> officially. Modulo some serious validation, there's no way I can
> upgrade to a current version and expect it to be stable.
> 
> 
>> But clearly we *do* need a fallback option for folks that are on an OS
that
>> doesn't provide CMake or that can't install packages using the
package
>> manager into the primary OS. I'm totally supportive of that use
case.
> 
> Right. And I totally want to support Chris and others to make our
> build system better.
> 
> I am definitely willing to take the hit and upgrade CMake on *all* my
> builders (current and future) to a *stable* CMake release if we can
> make it clear what we want.
> 
> If it's package based, having a minimum version is necessary, since
> some new distros don't have the old one. But it's also ok, because
> distros validate their packages and control their back-ports, so we
> know any update from them is reliable, no matter how new.
> 
> If it has to be compiled, than things are a little more complicated.
> We need to make sure people understand that *any* production
> environment (buildbot/Jenkins, release testing, etc) needs to use a
> stable release. We don't control our validation or release test
> environments as tight as we should, anyone can add a bot or be a
> tester, so having a loose requirement list makes the binaries less
> worth, and we do get bug reports on them due to incompatibilities. We
> want to decrease that problem, not increase.
> 
> I also want to make the releases a community process, where
> stakeholders (like Android, Apple, ARM, Sony, etc) can chime in and
> validate in their production environments, so that we know all people
> that use LLVM have a good, stable and robust base to build upon. Make
> it more flaky will counter those goals.
> 
> I don't want us to block people from using experimental CMake
> versions, but I think we must do so for the CMake scripts that go
> upstream. In a nutshell, we should mark a range, not a minimum.
> Preferably, a range includes a CMake that exists in Debian Jessie,
> since this is going to be the production release of most ARM and
> AArch64 machines for the foreseeable future. But stronger arguments
> may trump that, I understand.
> 
> 
>> If it would help
>> we could even bundle a copy of the CMake source code at a known good
>> snapshot in the LLVM project and write a wrapper script to bootstrap it
into
>> a known location and then use it for subsequent builds ... but that
seems
>> unnecessary to me.
> 
> No, having a range and *requiring* stable releases should be more than
enough.
> 
> 
>> I think removing impedance from the development of the CMake build, or
>> enabling new functionality such as properly bootstrapped runtime
libraries,
>> are absolutely things to weigh against the cost of using a newer tool.
> 
> I absolutely agree, but so far there were no technical arguments to
> support any of that.
> 
> All version proposals were hand wavy and based on their existence on
> this or that OS. I think we need to get a list of the features we
> need, match to the *stable* versions available from source, and make
> an informed choice. Just like we did with the compilers versions.
> 
> cheers,
> --renato

On 27 April 2016 at 18:41, Chris Bieneman <beanz at apple.com>
wrote:
> Renato, in your most recent email you comment about differentiating
*stable* vs random versions of CMake built from source. I believe as a community
our recommendation should be that people download CMake sources from
https://CMake.org/download/ instead of git. Then they get the source of a known
stable release. If people choose to pull random git hashes or tags, that is
their decision, but since the minimum version I'm proposing is widely
available I think it will be uncommon.
I'm guilty of cloning the git repo on my local tree, because it's
easier to do that than to find the link, download, untar, clean up,
etc. Then there's a bug, and you need to upgrade, "git pull" is
much
simpler than repeating the whole process again. :)

Also, recent "stable", as Chuck has shown, is less stable than
previous stable. I'd like to err in the side of caution.

> I've been working to try and un-do the horrible Darwin approach we have
because I think it has some serious problems, but an alternative solution would
be to extend the Darwin approach to every other platform. If you do this you
don't need ExternalProject, but you do need to do some really dirty hacks.
If you want to understand those hacks, just look at CompilerRTDarwinUtils.cmake
in compiler-rt. That is a bit of evil that I’m responsible for, and I’ll be
paying down that debt for a long time to come.
Point taken, it is horrible. (sorry)

> Apart from this we also have another problem. The build system makes
configuration decisions based on the compiler *at configuration time*. The
problem is you really want to configure compiler-rt (and the other runtimes)
*after* you've already built clang so the runtimes are configured and built
with the clang you just built. The only way to do that is with some mechanism
similar to ExternalProject.
<devil's advocate>We could come up with a set of rules that makes it
possible (not preferable) to do so at config time.</da>

Is that where the current complication comes from? What makes it so
horrible and ends up as a home brew version of ExternalProject?

> We could roll our own. At this point I'm going to put on my
"non-constructive reality" hat. I'm not going to do that.
Absolutely not. Ten shots to the head before we start rolling thing
our own that are perfectly covered by a tool we already use.

> Replicating ExternalProject would be a lot of work...
Just to be clear, I didn't mean that. If you're saying that, to get
the desired functionality we'll either need ExternalProject or
something identical to it, then the choice is clear. I was asking if
there was another (good, but less good) solution to the problem.

Rolling our own is not even a solution, much less a good one.

> As a data point, the one place in LLVM where we don't use
ExternalProject (and we should be) is the cross-compiling goop, and it is a
gigantic mess (see: CrossCompile.cmake and every mention of LLVM_NATIVE_BUILD in
TableGen.cmake). It is filled with bugs and in desperate need of disentangling.
This is another one of my sins that I need to repent.
Oh, so ExternalProject would also fix cross compilation!? I'm sold! :)

> I feel I should also point out that ExternalProject isn't a silver
bullet. It isn't going to solve all our problems, and since it is one of the
more actively changing parts of CMake we may find ourselves re-visiting this
conversation in a year or two talking about a newer version of CMake.
Right, this is an interesting point. I don't want to do this every
year, so let's be as reasonable as we can.

Is there anything in 3.5 that can really save us a lot of effort in
the current work?

I'm now using CMake 3.2.2 on all buildbots. If I have to move it up to
3.4.3, I'm fairly confident that there will be absolutely no problem
with it.

But as Chuck said, there were some crashes on 3.5.2 that needed 3.5.3,
and by using it on so many different platforms, we may uncover bugs,
and may have to roll back to 3.4 temporarily, and then forwards to
3.5, etc.

I really want to avoid that. But I also want to avoid doing this over
again next year.

Finally, Linaro cares more about Linux on ARM (v7+) than bare-metal,
but we can't just break the rest. I know there are people out there
that have infrastructure to test that kind of restricted environment,
not only on ARM, but also MIPS and old PPC32 stuff. I think they
should voice their concerns before we take any harsh decision.

cheers,
--renato

> On Apr 27, 2016, at 11:17 AM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> On 27 April 2016 at 18:41, Chris Bieneman <beanz at apple.com> wrote:
>> Renato, in your most recent email you comment about differentiating
*stable* vs random versions of CMake built from source. I believe as a community
our recommendation should be that people download CMake sources from
https://CMake.org/download/ instead of git. Then they get the source of a known
stable release. If people choose to pull random git hashes or tags, that is
their decision, but since the minimum version I'm proposing is widely
available I think it will be uncommon.
> 
> I'm guilty of cloning the git repo on my local tree, because it's
> easier to do that than to find the link, download, untar, clean up,
> etc. Then there's a bug, and you need to upgrade, "git pull"
is much
> simpler than repeating the whole process again. :)
> 
> Also, recent "stable", as Chuck has shown, is less stable than
> previous stable. I'd like to err in the side of caution.
> 
> 
>> I've been working to try and un-do the horrible Darwin approach we
have because I think it has some serious problems, but an alternative solution
would be to extend the Darwin approach to every other platform. If you do this
you don't need ExternalProject, but you do need to do some really dirty
hacks. If you want to understand those hacks, just look at
CompilerRTDarwinUtils.cmake in compiler-rt. That is a bit of evil that I’m
responsible for, and I’ll be paying down that debt for a long time to come.
> 
> Point taken, it is horrible. (sorry)
> 
> 
>> Apart from this we also have another problem. The build system makes
configuration decisions based on the compiler *at configuration time*. The
problem is you really want to configure compiler-rt (and the other runtimes)
*after* you've already built clang so the runtimes are configured and built
with the clang you just built. The only way to do that is with some mechanism
similar to ExternalProject.
> 
> <devil's advocate>We could come up with a set of rules that makes
it
> possible (not preferable) to do so at config time.</da>
> 
> Is that where the current complication comes from? What makes it so
> horrible and ends up as a home brew version of ExternalProject?
Recent CMakes have a few interesting things for us in ExternalProject.

CMake 3.1 added BUILD_ALWAYS (2a93843) which allows the build target of a
sub-project to always be called. This is really important because when you use
external projects the top-level build file doesn’t have the dependency
information for the sub-projects. So if you change sources in compiler-rt it
won’t know to rebuild compiler-rt. You need to force it to always invoke ninja
in the sub-project so that it will pick up changes.

Unfortunately even with CMake 3.1 BUILD_ALWAYS doesn’t actually work for Ninja
because of a bug that was fixed in CMake 3.4.1 (b6f4717).

I’m suggesting the version 3.4.3 because it is the last 3.4.x build, and the
CMake community is really strict about what gets put into patch releases.

> 
> 
>> We could roll our own. At this point I'm going to put on my
"non-constructive reality" hat. I'm not going to do that.
> 
> Absolutely not. Ten shots to the head before we start rolling thing
> our own that are perfectly covered by a tool we already use.
> 
> 
>> Replicating ExternalProject would be a lot of work...
> 
> Just to be clear, I didn't mean that. If you're saying that, to get
> the desired functionality we'll either need ExternalProject or
> something identical to it, then the choice is clear. I was asking if
> there was another (good, but less good) solution to the problem.
> 
> Rolling our own is not even a solution, much less a good one.
It isn’t necessarily something identical to it. ExternalProject isn’t actually
designed for this use, and it has loads of functionality we don’t need.
> 
> 
>> As a data point, the one place in LLVM where we don't use
ExternalProject (and we should be) is the cross-compiling goop, and it is a
gigantic mess (see: CrossCompile.cmake and every mention of LLVM_NATIVE_BUILD in
TableGen.cmake). It is filled with bugs and in desperate need of disentangling.
This is another one of my sins that I need to repent.
> 
> Oh, so ExternalProject would also fix cross compilation!? I'm sold! :)
And hopefully we can use it to make the optimized tablegen option more robust
too.
> 
> 
>> I feel I should also point out that ExternalProject isn't a silver
bullet. It isn't going to solve all our problems, and since it is one of the
more actively changing parts of CMake we may find ourselves re-visiting this
conversation in a year or two talking about a newer version of CMake.
> 
> Right, this is an interesting point. I don't want to do this every
> year, so let's be as reasonable as we can.
> 
> Is there anything in 3.5 that can really save us a lot of effort in
> the current work?
I don’t believe so. I’ve read the release notes
(https://cmake.org/cmake/help/v3.5/release/3.5.html
<https://cmake.org/cmake/help/v3.5/release/3.5.html>), and I don’t think
there is anything really important to us in them. I am interested in a few
things being discussed on the cmake-developers list though
(http://public.kitware.com/pipermail/cmake-developers/2016-January/027370.html
<http://public.kitware.com/pipermail/cmake-developers/2016-January/027370.html>).
It looks like that might make CMake 3.6, and it could be interesting for us.
That said, this is likely a case where we could easily support the old and new
versions without much problem and it doesn’t impact build correctness.
> 
> I'm now using CMake 3.2.2 on all buildbots. If I have to move it up to
> 3.4.3, I'm fairly confident that there will be absolutely no problem
> with it.
> 
> But as Chuck said, there were some crashes on 3.5.2 that needed 3.5.3,
> and by using it on so many different platforms, we may uncover bugs,
> and may have to roll back to 3.4 temporarily, and then forwards to
> 3.5, etc.
This is a big part of why I’m suggesting 3.4.3 instead of 3.5.0 or 3.5.1 which
are also widely available.
> 
> I really want to avoid that. But I also want to avoid doing this over
> again next year.
While I don’t want to advocate for us updating frequently “just because”, I do
think that if there are compelling reasons to update every year or two, we
shouldn’t be afraid to.

-Chris
> 
> Finally, Linaro cares more about Linux on ARM (v7+) than bare-metal,
> but we can't just break the rest. I know there are people out there
> that have infrastructure to test that kind of restricted environment,
> not only on ARM, but also MIPS and old PPC32 stuff. I think they
> should voice their concerns before we take any harsh decision.
> 
> cheers,
> --renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/45b39cc4/attachment.html>

> > Replicating ExternalProject would be a lot of work...
>
One approach commonly used with CMake modules that change frequently
upstream is for the project to keep a local copy and have a check in place
to use CMake's version if new enough.  For instance, in llvm's source
tree:

cmake/modules/ExternalProject.cmake:
if(CMAKE_VERSION VERSION_LESS "3.5.1")

include(${PROJECT_SOURCE_DIR}/cmake/modules/newcmake/ExternalProject.cmake)
else()
  include(${CMAKE_ROOT}/Modules/ExternalProject.cmake)
endif()

cmake/modules/newcmake/ExternalProject.cmake - Copy of the
ExternalProject.cmake shipped with 3.5.1

Then in the top level CMakeLists.txt, just include(ExternalProject).  It
will first load the version-check sicne that's in the module path and then
load CMake's copy if new enough, otherwise llvm's copy.  This way you
can
keep the minimum CMake version for the project at 3.4.3, but make sure that
your always using ExternaProject from at least 3.5.1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/23f42670/attachment.html>