llvm dev - Apr 2020 - Upgrading LLVM's minimum required CMake version

> On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dblaikie at gmail.com
<mailto:dblaikie at gmail.com>> wrote:
> I think it does make a difference how many things we ask new developers to
do to get up and running - because we've asked them to do one thing
doesn't mean it's low-cost to ask them to do another thing.
> 
> In this case I see it rather that if we ask them to do one quite big thing
already, we should be OK with what seems like a trivial one.
I strongly agree. I think Mehdi's point can be summarized as (Mehdi, feel
free to correct me):

    It's incredibly trivial to install CMake, so if a user is *already*
required to install a non-default toolchain (which is not so trivial), requiring
them to install a non-default CMake is not increasing the barrier by much.

Accepting that argument would mean that we don't have to consider
distributions where a non-default toolchain is *already* required as being
blocking for a CMake upgrade.

Louis
> 
> -- 
> Mehdi
> 
> 
>  
> 
> On Tue, Apr 7, 2020 at 11:20 AM Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> 
> On Tue, Apr 7, 2020 at 9:16 AM Chris Tetreault <ctetreau at quicinc.com
<mailto:ctetreau at quicinc.com>> wrote:
> > You're saying "doesn’t mean that we should" while
I've been saying in this situation that "we can", there is quite a
difference here I believe.
> 
>  
> 
> Technically “we can” do anything we want. We can always require that the
project be built with the current release candidate of CMake. That doesn’t mean
that we should.
> 
> 
> I don't feel you're really addressing the point, so I'll
phrased it in the other direction: is there a strong reason we should limit
ourself to the supported CMake on a given distribution where we already
can't build with the supported toolchain?
> I was saying I don't see why we should here: when we look at the list
of distribution we can bootstrap with the supported packages, I don't see
why make a difference here.
> 
> -- 
> Mehdi
> 
>  
>  
> 
> From: Mehdi AMINI <joker.eph at gmail.com <mailto:joker.eph at
gmail.com>>
> Sent: Tuesday, April 7, 2020 12:01 AM
> To: Chris Tetreault <ctetreau at quicinc.com <mailto:ctetreau at
quicinc.com>>
> Cc: Neil Nelson <nnelson at infowest.com <mailto:nnelson at
infowest.com>>; llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> Subject: [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake
version
> 
>  
> 
>  
> 
>  
> 
> On Mon, Apr 6, 2020 at 12:48 PM Chris Tetreault <ctetreau at quicinc.com
<mailto:ctetreau at quicinc.com>> wrote:
> 
> Every additional dependency that we force the user to manually install
(either by building from source, or adding some new PPA to their ubuntu system),
raises the barrier to entry that much higher.
> 
>  
> 
> Right: I think it is important to quantify the "that much
higher", I believe that the commands I showed earlier (which can be put in
a script in the repo) is really as low as one can expect.
> 
>  
> 
>  
> 
> Just because we may require the user to manually install some newer
compiler on their system doesn’t mean that we should also require them to
install some newer CMake than what’s on their system.
> 
>  
> 
> You're saying "doesn’t mean that we should" while I've
been saying in this situation that "we can", there is quite a
difference here I believe.
> 
>  
> 
> -- 
> 
> Mehdi
> 
>  
> 
>  
> 
> (unless it is actually necessary, but we’ve beaten that dead horse long
enough)
> 
>  
> 
> I agree with Neil’s interpretation that the definition of “supported” being
used here is default system packages and not third party repos that claim to
work for that system.
> 
>  
> 
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Mehdi AMINI
via llvm-dev
> Sent: Saturday, April 4, 2020 2:11 PM
> To: Neil Nelson <nnelson at infowest.com <mailto:nnelson at
infowest.com>>
> Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
> Subject: [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake
version
> 
>  
> 
>  
> 
>  
> 
> On Sat, Apr 4, 2020 at 12:48 PM Neil Nelson via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> 'Supported' means that it comes from the packages available from
the distribution that can be seen via this page.
> 
> https://packages.ubuntu.com/ <https://packages.ubuntu.com/>
> These packages have been processed by the Ubuntu community to obtain a
reliability expectation that would not apply, for example, to a PPA.
> 
>  
> 
> Right, so I'm looking for an answer to my question, I'll try make
it more concrete what I mean by "in cases where we already requires a more
recent compiler than the default one available".
> 
> If I take Xenial for instance, the most recent GCC version is 5.4.0 as far
as I can tell: https://packages.ubuntu.com/xenial/devel/gcc-5
<https://packages.ubuntu.com/xenial/devel/gcc-5> ; assuming LLVM would
move at some point to require a more recent version than 5.4, it would mean that
you couldn't build LLVM with the packages available on Xenial. In this
situation (which I referred to as "cases where we already requires a more
recent compiler than the default one available") we already expect the user
to get a toolchain from a non-primary package source on this distribution, and
if we do this for the toolchain already I would expect that we should be able to
do it as well for CMake (again: for a given distribution/version).
> 
>  
> 
> The difference between installing or building Clang and LLVM from original
sources as against installing versions available from the distribution
> 
> I don't understand this sentence?
> 
>  
> 
> when compared to doing the same with cmake, is that the user accepts the
inherent risks from Clang and LLVM, but Clang and LLVM can not accept the risks
from the cmake group and then expect the user to merely assume that there are no
additional risks from installing cmake.
> 
> Maybe a nit here, but there is no need to *install* CMake: it could be
trivially build in the build directory. We are talking about a trivial step
here:
> 
>  
> 
> # Inside llvm-project/
> 
> $ mkdir build/ && cd build/
> 
> # bootstrap CMake
> 
> $ wget
https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz
<https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz>
> $ echo
"b74c05b55115eacc4fa2b77a814981dbda05cdc95a53e279fe16b7b272f00847 
cmake-3.17.0.tar.gz" | sha256sum -c
> 
> $ tar -xf cmake-3.17.0.tar.gz && cd cmake-3.17.0 &&
./bootstrap && make
> 
> # Done, cmake is usable, *nothing* is installed on the user system,
everything is self-contained *inside* the build directory itself.
> 
> $ ./cmake-3.17.0/bin/cmake ../llvm/ -D.... # build LLVM as usual.
> 
>  
> 
>  
> 
>  
> 
> The distributions are not merely just collections of software, they are
collections of software that have some guarantee of working well together and
without bugs and other issues because they have been used and tested by that use
in the distribution community.
> 
> The importance of this distinction between the quality of software expected
in a distribution as against installing directly from source is apparently lost
on those who did not live through the pre-distribution days. During that time we
had to gather up the dependencies ourselves, trying to get the correct versions,
hoping that the software compiled and worked with the other dependencies, and
hope we did not install malware and hackware. And quite often it was a futile
attempt to gather together software dependencies of any size.
> 
> Those who lived through that time remember it as the dark-ages of long ago,
never to be seen again.
> 
> Been there, done that... (actually suffered from that).
> 
>  
> 
> I claim this is just not the same situation here: CMake is a self-contained
dependencies and as shown above does not need to escape anywhere outside the
build directory.
> 
>  
> 
> -- 
> 
> Mehdi
> 
>  
> 
>  
> 
> On 4/4/20 11:48 AM, Mehdi AMINI via llvm-dev wrote:
> 
>  
> 
>  
> 
> On Thu, Apr 2, 2020 at 10:49 AM Shoaib Meenai via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> I’m in favor of all this. Thanks for volunteering! I’m happy to help out in
whatever way.
> 
>  
> 
> Some things it might be worth figuring out for future upgrades:
> 
> * If we want to limit ourselves to CMake versions supported by LTS releases
of distros, which distros should we consider, and how far back should we go
(i.e. is it just the latest LTS or the last two LTS versions)?
> 
>  
> 
> Can you clarify what "supported" means? Does it include PPA on
ubuntu for example?
> 
> I wouldn't limit ourselves artificially to the version of CMake
"natively" available on an OS in cases where we already requires a
more recent compiler than the default one available: if we consider OK to
require as user to build clang or gcc from source or use a PPA, we should be OK
the same way with CMake.
> 
>  
> 
>  
> 
> * For platforms like Ubuntu where CMake publishes its own packages (that
you can install via the platform’s package manager), do those count, or do we
only consider the CMake that comes in the OS packages?
> 
> * Do we have any limitations around how often/when we upgrade? You’re tying
the upgrade to after the branch, which is pretty standard, but e.g. if we wanted
to upgrade to 3.8.0 now and then upgrade to 3.13.4 after the branch, would
people be okay with that, or should we limit upgrades to just shortly after a
branch?
> 
>  
> 
> From: <ldionne at apple.com <mailto:ldionne at apple.com>> on
behalf of Louis Dionne <ldionne at apple.com <mailto:ldionne at
apple.com>>
> Date: Thursday, April 2, 2020 at 7:20 AM
> To: Shoaib Meenai <smeenai at fb.com <mailto:smeenai at
fb.com>>
> Cc: "llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>" <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>, Chris Bieneman <beanz at apple.com <mailto:beanz
at apple.com>>, Petr Hosek <phosek at chromium.org <mailto:phosek at
chromium.org>>, Saleem Abdulrasool <compnerd at compnerd.org
<mailto:compnerd at compnerd.org>>, "tstellar at redhat.com
<mailto:tstellar at redhat.com>" <tstellar at redhat.com
<mailto:tstellar at redhat.com>>
> Subject: Re: Upgrading LLVM's minimum required CMake version
> 
>  
> 
> Okay, so we've had some discussion on this thread, and although some
people (including me) would like a more aggressive policy, I believe the
following will not get any objection (based on the thread). On April 23rd 2020,
Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the lower bound for
LTS distributions be 3.13.4, and so I suggest we upgrade to that. Here's a
proposed process:
> 
>  
> 
> 1. Immediately add a CMake warning in <root>/llvm/CMakeLists.txt
saying that CMake 3.13.4 will be the new minimum version starting with LLVM
12.0.0, and mentioning the versions used in various LTSes.
> 
> 2. Immediately send a courtesy heads-up email to all build-bot owners
telling them about the upcoming change.
> 
> 3. Right after we branch off the release branch for LLVM 11.0.0 (the next
one), make the minimum CMake version required be 3.13.4.
> 
> 4. Iterate on (3) until all bots are migrated.
> 
> 5. Send a message to the list saying the bump is complete. At that time,
projects are free to start using features from 3.13.4.
> 
>  
> 
> Unless someone else absolutely wants to bite the bullet, I volunteer to do
the above steps.
> 
>  
> 
> Thoughts?
> 
>  
> 
> Louis
> 
>  
> 
>  
> 
> On Mar 26, 2020, at 16:07, Shoaib Meenai <smeenai at fb.com
<mailto:smeenai at fb.com>> wrote:
> 
>  
> 
> We had this discussion a few months ago and it petered out, and it’s
recently been revived in the context of upgrading the CMake version specifically
for libc++ (at which point people suggested upgrading the CMake version used by
all of LLVM), so let’s try to move this forward.
> 
> Our current required minimum version is CMake 3.4.3, which was released on
January 25th 2016. It’s interesting to note that LLVM started requiring 3.4.3 on
May 31st 2016, which was just 4 months after its release.
> 
> Let’s look at the CMake versions available on various distros and operating
systems. I’m unfamiliar with many of these, so I apologize if I get something
wrong. (I’m using pkgs.org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__pkgs.org&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=S6Qvuq5DqECZFfItkAJOL5xjTSp1psRWYtq_WOnXt_o&e=>
for most of this information.)
> * RHEL 6 (released Nov 10th 2010) : 3.6.1 (via EPEL)
> * RHEL 7 (released June 10th 2014): 3.14.7 (via EPEL)
> * RHEL 8 (released May 7th 2019): 3.11.4 (maybe pkgs.org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__pkgs.org&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=S6Qvuq5DqECZFfItkAJOL5xjTSp1psRWYtq_WOnXt_o&e=>
is screwy on this one, because it doesn’t make sense that RHEL 7 should have a
newer available version than RHEL 8)
> * Debian 9 (released June 17th 2017): 3.7.2
> * Debian 10 (released July 6th 2019): 3.13.4
> * Ubuntu 16.04 LTS (released April 21st 2016): 3.5.1
> * Ubuntu 18.04 LTS (released April 26th 2018): 3.10.2
> * FreeBSD 11 (released October 10th 2016): 3.15.5 (presumably upgraded in a
point release)
> * FreeBSD 12 (released December 11th 2018): 3.15.5 (presumably upgraded in
a point release)
> * NetBSD 8.1 (released May 31st 2019): 3.16.1
> * NetBSD 9.0 (released February 14th 2020): 3.16.1
> * OpenBSD: couldn’t find the version
> * macOS: latest version is readily available through Homebrew
> * Windows: You can install it yourself or use the one bundled with Visual
Studio. I don't know what versions are bundled with Visual Studio; some
searching suggests Visual Studio 2017 has CMake 3.12 and Visual Studio 2019 has
3.15, though I have no confirmation of that.
> 
> Note that CMake provides prebuilt binaries for Linux, macOS, and Windows,
and it’s also straightforward to build from source (it has very conservative
compiler requirements). One suggestion that was brought up in the past was for
LLVM’s build system to just download a newer version of CMake if you attempted
to build it using one that was too old, but there was opposition [1]. There was
also a suggestion to have a script in LLVM to download and build CMake for you,
but there were mixed opinions on this too [2], particularly since many
developers might prefer downloading a binary release to building from source
themselves (though of course the script could also download binary releases if
applicable). I personally think downloading or building CMake yourself isn’t a
high barrier for anyone wanting to build LLVM (and in particular it’s *much*
more straightforward than building LLVM itself), but I can understand why people
would prefer to stick to versions available in distros.
> 
> Another suggestion that came up last time was to set a policy for upgrading
CMake versions on some regular basis. The opposition to this was that we should
upgrade CMake versions only when a newer version has a compelling enough feature
to justify upgrading, rather than always upgrading. I can see arguments for both
approaches, but we should definitely at least think about the benefits we can
get from upgrading versions. I've gone through the CMake release notes and
highlighted features which seemed potentially valuable for LLVM. Note that
I'm only highlighting features for which our minimum CMake version would
have to be bumped up in order for our build system to take advantage of. There
are other useful features in newer CMake versions, but you can take advantage of
them just by using a newer CMake yourself. For example, 3.9 loosens the
dependencies of object compilation, which should result in faster Ninja builds.
> 
> CMake 3.5 (released March 8th 2016):
> * install(DIRECTORY) supports generator expressions
> 
> CMake 3.6 (released July 7th 2016):
> * install() supports EXCLUDE_FROM_ALL
> * list() supports FILTER to filter by regular expression
> * Subninja support, which could theoretically be used for much faster
runtimes builds, although in practice we probably want to make ExternalProject
support this directly instead of trying to layer our own meta-build system on
top
> * CMAKE_TRY_COMPILE_TARGET_TYPE to tell try_compile to build a static
library instead of an executable, which will greatly simplify the compiler-rt
build
> 
> CMake 3.7 (released November 11th 2016):
> * New if() comparison operators LESS_EQUAL, GREATER_EQUAL, STRLESS_EQUAL,
STRGREATER_EQUAL, VERSION_LESS_EQUAL, and VERSION_GREATER_EQUAL
> 
> CMake 3.8 (released April 10th 2017):
> * Compile features for C++17, which is required to build libc++ correctly
> * Support for compile features for specific C++ features instead of only
being able to specify standard versions
> * rpath support via BUILD_RPATH target property and CMAKE_BUILD_RPATH
variable
> * Apple framework support for static libraries
> * New swig_add_library command in the UseSWIG module
> * New generator expression $<IF:cond,true-value,false-value>
> 
> CMake 3.9 (released July 18th 2017):
> * install(TARGETS) and install(EXPORTS) support for object libraries, which
will simplify the compiler-rt build
> * TARGET_OBJECTS generator expression support in add_custom_command and
file(GENERATE)
> * $<TARGET_BUNDLE_DIR:tgt> and $<TARGET_BUNDLE_CONTENT_DIR:tgt>
generator expressions for Apple bundles
> 
> CMake 3.10 (released November 20th 2017):
> * include_guard() command for proper guarding against double includes of
CMake scripts
> * An interesting aside is that this is the first verion of CMake to require
C++11 to build, which should give a good sense of how conservative they are
about compiler requirements
> 
> CMake 3.11 (released March 28th 2018):
> * add_library() and add_executable() can be called without sources as long
as target_sources() is used later
> * target_compile_{definitions,features,options},
target_include_directories(), target_sources(), and target_link_libraries() can
set the corresponding INTERFACE_* properties on imported targets
> * COMPILE_DEFINITIONS supports generator expressions
> * COMPILE_OPTIONS source file property added
> * INCLUDE_DIRECTORIES source file property added
> * Interface libraries support custom properites
> 
> CMake 3.12 (released July 17th 2018):
> * add_compile_definitions() added to add compile definitions for targets
(to avoid the global pollution caused by add_definitions())
> * cmake_minimum_required() supports a version range to indicate tested
CMake versions and set policies accordingly
> * file(TOUCH) and file(TOUCH_NOCREATE) added
> * list(JOIN), list(SUBLIST) and list(TRANSFORM) added
> * string(JOIN) added
> * SHELL: prefix support in target_compile_options to avoid errant
deduplication
> * target_link_libraries() supports object libraries and propagates usage
requirements
> * EXPORT_PROPERTIES target property to control the target properties
exported by export() and install(EXPORT)
> * FindLibXml2 provides imported targets
> * New FindPython, FindPython2, and FindPython3 modules to ease location
Python and selecting a specific version
> * Modernization of UseSWIG module
> * New generator expressions $<GENEX_EVAL:...>,
$<TARGET_GENEX_EVAL:target,...>, $<IN_LIST:...>,
$<TARGET_EXISTS:...> and $<TARGET_NAME_IF_EXISTS:...>
> * Compile features support for C++20
> 
> CMake 3.13 (released November 20th 2018):
> * cmake -E create_symlink supported on Windows
> * target_link_directories() and target_link_options() commands to set link
options instead of awkwardly having to use target_link_libraries() for this
purpose
> * UseSWIG can manage INCLUDE_DIRECTORIES for SWIG compilation
> 
> CMake 3.14 (released March 14th 2019):
> * file(CREATE_LINK) to create hard or symbolic links
> * if(DEFINED CACHE{VAR}) for checking if a cache variable is defined
> * $<IN_LIST:...> generator expression correctly handles empty
argument
> * Fixes for object library linking propagation
> * Link options to manage position independent executables added
automatically
> 
> CMake 3.15 (released July 17th 2019):
> * list(PREPEND), list(POP_FRONT) and list(POP_BACK) added
> * New message() types NOTICE, VERBOSE, DEBUG and TRACE
> * string(REPEAT) added
> * MSVC_RUNTIME_LIBRARY target property and CMAKE_MSVC_RUNTIME_LIBRARY
variable to select the runtime library type for MSVC
> * $<C_COMPILER_ID:...>, $<CXX_COMPILER_ID:...>,
$<COMPILE_LANGUAGE:...>, and $<PLATFORM_ID:...> generator
expressions support matching one value from a list
> * $<COMPILE_LANG_AND_ID:...> generator expression added
> * $<FILTER:list,INCLUDE|EXCLUDE,regex> generator expression added
> * $<REMOVE_DUPLICATES:list> generator expression added
> * New $<TARGET_FILE*> generator expressions added:
$<TARGET_FILE_PREFIX:...>, $<TARGET_FILE_BASE_NAME:...>,
$<TARGET_FILE_SUFFIX:...>, $<TARGET_LINKER_FILE_PREFIX:...>,
$<TARGET_LINKER_FILE_BASE_NAME:...>,
$<TARGET_LINKER_FILE_SUFFIX:...>, $<TARGET_PDB_FILE_BASE_NAME:...>
> * $<TARGET_OBJECTS:...> generator expression supports executables and
static, shared, and module libraries
> 
> CMake 3.16 (released November 26th 2019):
> * Support for generator expressions in BUILD_RPATH and INSTALL_RPATH
> 
> CMake 3.17 (released March 20th 2020):
> * Ninja Multi-Config generator, which among other things would greatly
simplify LLVM_OPTIMIZED_TABLEGEN
> * foreach(ZIP_LISTS) added to iterate multiple lists simultaneously
> * New message() keywords CHECK_START, CHECK_PASS, and CHECK_FAIL
> * INSTALL_NAME_DIR supports generator expressions
> 
> Our build system is incredibly complex, and many of these features can be
used to clean it up and make it much more maintainable. I would personally like
us to at least bump up to CMake 3.12. I also do think it's worth
establishing a policy and process around upgrading CMake versions, since newer
versions keep on adding useful features (particularly better generator
expression support), and we want to be able to keep taking advantage of them.
> 
> [1] http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DNovember_136485.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=HtGj57-MndDqyK71vXRwheQXms3WKx9rT-8WAVyTB3c&e=>
> [2] http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DNovember_136488.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=hHrZYrGk0WStJ3TjjIsXg2NMvVUP-f4woTFtaFlYkG8&e=>
>  
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>  
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200408/68fe35b9/attachment.html>

On Wed, Apr 8, 2020 at 9:02 AM Louis Dionne <ldionne at apple.com> wrote:
>
>
> On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dblaikie at gmail.com>
wrote:
>
>> I think it does make a difference how many things we ask new developers
>> to do to get up and running - because we've asked them to do one
thing
>> doesn't mean it's low-cost to ask them to do another thing.
>>
>
> In this case I see it rather that if we ask them to do one quite big thing
> already, we should be OK with what seems like a trivial one.
>
>
> I strongly agree. I think Mehdi's point can be summarized as (Mehdi,
feel
> free to correct me):
>
>     It's incredibly trivial to install CMake, so if a user is *already*
> required to install a non-default toolchain (which is not so trivial),
> requiring them to install a non-default CMake is not increasing the barrier
> by much.
>
Thanks, this is my point indeed!

I think it is even slightly stronger than what you wrote since you don't
even need to *install* CMake as it can be built and used directly from the
build directory: it is entirely non-intrusive on the system.

-- 
Mehdi


>
> Accepting that argument would mean that we don't have to consider
> distributions where a non-default toolchain is *already* required as being
> blocking for a CMake upgrade.
>
> Louis
>
>
> --
> Mehdi
>
>
>
>
>>
>> On Tue, Apr 7, 2020 at 11:20 AM Mehdi AMINI via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Apr 7, 2020 at 9:16 AM Chris Tetreault <ctetreau at
quicinc.com>
>>> wrote:
>>>
>>>> > You're saying "doesn’t mean that we should"
while I've been saying in
>>>> this situation that "we can", there is quite a
difference here I believe.
>>>>
>>>>
>>>>
>>>> Technically “we can” do anything we want. We can always require
that
>>>> the project be built with the current release candidate of
CMake. That
>>>> doesn’t mean that we should.
>>>>
>>>
>>> I don't feel you're really addressing the point, so
I'll phrased it in
>>> the other direction: is there a strong reason we should limit
ourself to
>>> the supported CMake on a given distribution where we already
can't build
>>> with the supported toolchain?
>>> I was saying I don't see why we should here: when we look at
the list of
>>> distribution we can bootstrap with the supported packages, I
don't see why
>>> make a difference here.
>>>
>>> --
>>> Mehdi
>>>
>>>
>>>
>>>>
>>>>
>>>> *From:* Mehdi AMINI <joker.eph at gmail.com>
>>>> *Sent:* Tuesday, April 7, 2020 12:01 AM
>>>> *To:* Chris Tetreault <ctetreau at quicinc.com>
>>>> *Cc:* Neil Nelson <nnelson at infowest.com>; llvm-dev at
lists.llvm.org
>>>> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum
required
>>>> CMake version
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Apr 6, 2020 at 12:48 PM Chris Tetreault <ctetreau at
quicinc.com>
>>>> wrote:
>>>>
>>>> Every additional dependency that we force the user to manually
install
>>>> (either by building from source, or adding some new PPA to
their ubuntu
>>>> system), raises the barrier to entry that much higher.
>>>>
>>>>
>>>>
>>>> Right: I think it is important to quantify the "that much
higher", I
>>>> believe that the commands I showed earlier (which can be put in
a script in
>>>> the repo) is really as low as one can expect.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Just because we may require the user to manually install some
newer
>>>> compiler on their system doesn’t mean that we should also
require them to
>>>> install some newer CMake than what’s on their system.
>>>>
>>>>
>>>>
>>>> You're saying "doesn’t mean that we should" while
I've been saying in
>>>> this situation that "we can", there is quite a
difference here I believe.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Mehdi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> (unless it is actually necessary, but we’ve beaten that dead
horse long
>>>> enough)
>>>>
>>>>
>>>>
>>>> I agree with Neil’s interpretation that the definition of
“supported”
>>>> being used here is default system packages and not third party
repos that
>>>> claim to work for that system.
>>>>
>>>>
>>>>
>>>> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On
Behalf Of *Mehdi
>>>> AMINI via llvm-dev
>>>> *Sent:* Saturday, April 4, 2020 2:11 PM
>>>> *To:* Neil Nelson <nnelson at infowest.com>
>>>> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
>>>> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum
required
>>>> CMake version
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Apr 4, 2020 at 12:48 PM Neil Nelson via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>> 'Supported' means that it comes from the packages
available from the
>>>> distribution that can be seen via this page.
>>>>
>>>> https://packages.ubuntu.com/
>>>>
>>>> These packages have been processed by the Ubuntu community to
obtain a
>>>> reliability expectation that would not apply, for example, to a
PPA.
>>>>
>>>>
>>>>
>>>> Right, so I'm looking for an answer to my question,
I'll try make it
>>>> more concrete what I mean by "in cases where we already
requires a more
>>>> recent compiler than the default one available".
>>>>
>>>> If I take Xenial for instance, the most recent GCC version is
5.4.0 as
>>>> far as I can tell:
https://packages.ubuntu.com/xenial/devel/gcc-5 ;
>>>> assuming LLVM would move at some point to require a more recent
version
>>>> than 5.4, it would mean that you couldn't build LLVM with
the packages
>>>> available on Xenial. In this situation (which I referred to as
"cases where
>>>> we already requires a more recent compiler than the default one
available")
>>>> we already expect the user to get a toolchain from a
non-primary package
>>>> source on this distribution, and if we do this for the
toolchain already I
>>>> would expect that we should be able to do it as well for CMake
(again: for
>>>> a given distribution/version).
>>>>
>>>>
>>>>
>>>> The difference between installing or building Clang and LLVM
from
>>>> original sources as against installing versions available from
the
>>>> distribution
>>>>
>>>> I don't understand this sentence?
>>>>
>>>>
>>>>
>>>> when compared to doing the same with cmake, is that the user
accepts
>>>> the inherent risks from Clang and LLVM, but Clang and LLVM can
not accept
>>>> the risks from the cmake group and then expect the user to
merely assume
>>>> that there are no additional risks from installing cmake.
>>>>
>>>> Maybe a nit here, but there is no need to *install* CMake: it
could be
>>>> trivially build in the build directory. We are talking about a
trivial step
>>>> here:
>>>>
>>>>
>>>>
>>>> # Inside llvm-project/
>>>>
>>>> $ mkdir build/ && cd build/
>>>>
>>>> # bootstrap CMake
>>>>
>>>> $ wget
>>>>
https://github.com/Kitware/CMake/releases/download/v3.17.0/cmake-3.17.0.tar.gz
>>>>
>>>> $ echo
>>>>
"b74c05b55115eacc4fa2b77a814981dbda05cdc95a53e279fe16b7b272f00847
>>>>  cmake-3.17.0.tar.gz" | sha256sum -c
>>>>
>>>> $ tar -xf cmake-3.17.0.tar.gz && cd cmake-3.17.0
&& ./bootstrap && make
>>>>
>>>> # Done, cmake is usable, *nothing* is installed on the user
system,
>>>> everything is self-contained *inside* the build directory
itself.
>>>>
>>>> $ ./cmake-3.17.0/bin/cmake ../llvm/ -D.... # build LLVM as
usual.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The distributions are not merely just collections of software,
they are
>>>> collections of software that have some guarantee of working
well together
>>>> and without bugs and other issues because they have been used
and tested by
>>>> that use in the distribution community.
>>>>
>>>> The importance of this distinction between the quality of
software
>>>> expected in a distribution as against installing directly from
source is
>>>> apparently lost on those who did not live through the
pre-distribution
>>>> days. During that time we had to gather up the dependencies
ourselves,
>>>> trying to get the correct versions, hoping that the software
compiled and
>>>> worked with the other dependencies, and hope we did not install
malware and
>>>> hackware. And quite often it was a futile attempt to gather
together
>>>> software dependencies of any size.
>>>>
>>>> Those who lived through that time remember it as the dark-ages
of long
>>>> ago, never to be seen again.
>>>>
>>>> Been there, done that... (actually suffered from that).
>>>>
>>>>
>>>>
>>>> I claim this is just not the same situation here: CMake is a
>>>> self-contained dependencies and as shown above does not need to
escape
>>>> anywhere outside the build directory.
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Mehdi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 4/4/20 11:48 AM, Mehdi AMINI via llvm-dev wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 2, 2020 at 10:49 AM Shoaib Meenai via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>> I’m in favor of all this. Thanks for volunteering! I’m happy to
help
>>>> out in whatever way.
>>>>
>>>>
>>>>
>>>> Some things it might be worth figuring out for future upgrades:
>>>>
>>>> * If we want to limit ourselves to CMake versions supported by
LTS
>>>> releases of distros, which distros should we consider, and how
far back
>>>> should we go (i.e. is it just the latest LTS or the last two
LTS versions)?
>>>>
>>>>
>>>>
>>>> Can you clarify what "supported" means? Does it
include PPA on ubuntu
>>>> for example?
>>>>
>>>> I wouldn't limit ourselves artificially to the version of
CMake
>>>> "natively" available on an OS in cases where we
already requires a more
>>>> recent compiler than the default one available: if we consider
OK to
>>>> require as user to build clang or gcc from source or use a PPA,
we should
>>>> be OK the same way with CMake.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * For platforms like Ubuntu where CMake publishes its own
packages
>>>> (that you can install via the platform’s package manager), do
those count,
>>>> or do we only consider the CMake that comes in the OS packages?
>>>>
>>>> * Do we have any limitations around how often/when we upgrade?
You’re
>>>> tying the upgrade to after the branch, which is pretty
standard, but e.g.
>>>> if we wanted to upgrade to 3.8.0 now and then upgrade to 3.13.4
after the
>>>> branch, would people be okay with that, or should we limit
upgrades to just
>>>> shortly after a branch?
>>>>
>>>>
>>>>
>>>> *From: *<ldionne at apple.com> on behalf of Louis Dionne
<
>>>> ldionne at apple.com>
>>>> *Date: *Thursday, April 2, 2020 at 7:20 AM
>>>> *To: *Shoaib Meenai <smeenai at fb.com>
>>>> *Cc: *"llvm-dev at lists.llvm.org" <llvm-dev at
lists.llvm.org>, Chris
>>>> Bieneman <beanz at apple.com>, Petr Hosek <phosek at
chromium.org>, Saleem
>>>> Abdulrasool <compnerd at compnerd.org>, "tstellar at
redhat.com" <
>>>> tstellar at redhat.com>
>>>> *Subject: *Re: Upgrading LLVM's minimum required CMake
version
>>>>
>>>>
>>>>
>>>> Okay, so we've had some discussion on this thread, and
although some
>>>> people (including me) would like a more aggressive policy, I
believe the
>>>> following will not get any objection (based on the thread). On
April 23rd
>>>> 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will
make the
>>>> lower bound for LTS distributions be 3.13.4, and so I suggest
we upgrade to
>>>> that. Here's a proposed process:
>>>>
>>>>
>>>>
>>>> 1. Immediately add a CMake warning in
<root>/llvm/CMakeLists.txt
>>>> saying that CMake 3.13.4 will be the new minimum version
starting with LLVM
>>>> 12.0.0, and mentioning the versions used in various LTSes.
>>>>
>>>> 2. Immediately send a courtesy heads-up email to all build-bot
owners
>>>> telling them about the upcoming change.
>>>>
>>>> 3. Right after we branch off the release branch for LLVM 11.0.0
(the
>>>> next one), make the minimum CMake version required be 3.13.4.
>>>>
>>>> 4. Iterate on (3) until all bots are migrated.
>>>>
>>>> 5. Send a message to the list saying the bump is complete. At
that
>>>> time, projects are free to start using features from 3.13.4.
>>>>
>>>>
>>>>
>>>> Unless someone else absolutely wants to bite the bullet, I
volunteer to
>>>> do the above steps.
>>>>
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>>
>>>> Louis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 26, 2020, at 16:07, Shoaib Meenai <smeenai at
fb.com> wrote:
>>>>
>>>>
>>>>
>>>> We had this discussion a few months ago and it petered out, and
it’s
>>>> recently been revived in the context of upgrading the CMake
version
>>>> specifically for libc++ (at which point people suggested
upgrading the
>>>> CMake version used by all of LLVM), so let’s try to move this
forward.
>>>>
>>>> Our current required minimum version is CMake 3.4.3, which was
released
>>>> on January 25th 2016. It’s interesting to note that LLVM
started requiring
>>>> 3.4.3 on May 31st 2016, which was just 4 months after its
release.
>>>>
>>>> Let’s look at the CMake versions available on various distros
and
>>>> operating systems. I’m unfamiliar with many of these, so I
apologize if I
>>>> get something wrong. (I’m using pkgs.org
>>>>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__pkgs.org&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=S6Qvuq5DqECZFfItkAJOL5xjTSp1psRWYtq_WOnXt_o&e=>
>>>> for most of this information.)
>>>> * RHEL 6 (released Nov 10th 2010) : 3.6.1 (via EPEL)
>>>> * RHEL 7 (released June 10th 2014): 3.14.7 (via EPEL)
>>>> * RHEL 8 (released May 7th 2019): 3.11.4 (maybe pkgs.org
>>>>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__pkgs.org&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=S6Qvuq5DqECZFfItkAJOL5xjTSp1psRWYtq_WOnXt_o&e=>
>>>> is screwy on this one, because it doesn’t make sense that RHEL
7 should
>>>> have a newer available version than RHEL 8)
>>>> * Debian 9 (released June 17th 2017): 3.7.2
>>>> * Debian 10 (released July 6th 2019): 3.13.4
>>>> * Ubuntu 16.04 LTS (released April 21st 2016): 3.5.1
>>>> * Ubuntu 18.04 LTS (released April 26th 2018): 3.10.2
>>>> * FreeBSD 11 (released October 10th 2016): 3.15.5 (presumably
upgraded
>>>> in a point release)
>>>> * FreeBSD 12 (released December 11th 2018): 3.15.5 (presumably
upgraded
>>>> in a point release)
>>>> * NetBSD 8.1 (released May 31st 2019): 3.16.1
>>>> * NetBSD 9.0 (released February 14th 2020): 3.16.1
>>>> * OpenBSD: couldn’t find the version
>>>> * macOS: latest version is readily available through Homebrew
>>>> * Windows: You can install it yourself or use the one bundled
with
>>>> Visual Studio. I don't know what versions are bundled with
Visual Studio;
>>>> some searching suggests Visual Studio 2017 has CMake 3.12 and
Visual Studio
>>>> 2019 has 3.15, though I have no confirmation of that.
>>>>
>>>> Note that CMake provides prebuilt binaries for Linux, macOS,
and
>>>> Windows, and it’s also straightforward to build from source (it
has very
>>>> conservative compiler requirements). One suggestion that was
brought up in
>>>> the past was for LLVM’s build system to just download a newer
version of
>>>> CMake if you attempted to build it using one that was too old,
but there
>>>> was opposition [1]. There was also a suggestion to have a
script in LLVM to
>>>> download and build CMake for you, but there were mixed opinions
on this too
>>>> [2], particularly since many developers might prefer
downloading a binary
>>>> release to building from source themselves (though of course
the script
>>>> could also download binary releases if applicable). I
personally think
>>>> downloading or building CMake yourself isn’t a high barrier for
anyone
>>>> wanting to build LLVM (and in particular it’s *much* more
straightforward
>>>> than building LLVM itself), but I can understand why people
would prefer to
>>>> stick to versions available in distros.
>>>>
>>>> Another suggestion that came up last time was to set a policy
for
>>>> upgrading CMake versions on some regular basis. The opposition
to this was
>>>> that we should upgrade CMake versions only when a newer version
has a
>>>> compelling enough feature to justify upgrading, rather than
always
>>>> upgrading. I can see arguments for both approaches, but we
should
>>>> definitely at least think about the benefits we can get from
upgrading
>>>> versions. I've gone through the CMake release notes and
highlighted
>>>> features which seemed potentially valuable for LLVM. Note that
I'm only
>>>> highlighting features for which our minimum CMake version would
have to be
>>>> bumped up in order for our build system to take advantage of.
There are
>>>> other useful features in newer CMake versions, but you can take
advantage
>>>> of them just by using a newer CMake yourself. For example, 3.9
loosens the
>>>> dependencies of object compilation, which should result in
faster Ninja
>>>> builds.
>>>>
>>>> CMake 3.5 (released March 8th 2016):
>>>> * install(DIRECTORY) supports generator expressions
>>>>
>>>> CMake 3.6 (released July 7th 2016):
>>>> * install() supports EXCLUDE_FROM_ALL
>>>> * list() supports FILTER to filter by regular expression
>>>> * Subninja support, which could theoretically be used for much
faster
>>>> runtimes builds, although in practice we probably want to make
>>>> ExternalProject support this directly instead of trying to
layer our own
>>>> meta-build system on top
>>>> * CMAKE_TRY_COMPILE_TARGET_TYPE to tell try_compile to build a
static
>>>> library instead of an executable, which will greatly simplify
the
>>>> compiler-rt build
>>>>
>>>> CMake 3.7 (released November 11th 2016):
>>>> * New if() comparison operators LESS_EQUAL, GREATER_EQUAL,
>>>> STRLESS_EQUAL, STRGREATER_EQUAL, VERSION_LESS_EQUAL, and
>>>> VERSION_GREATER_EQUAL
>>>>
>>>> CMake 3.8 (released April 10th 2017):
>>>> * Compile features for C++17, which is required to build libc++
>>>> correctly
>>>> * Support for compile features for specific C++ features
instead of
>>>> only being able to specify standard versions
>>>> * rpath support via BUILD_RPATH target property and
CMAKE_BUILD_RPATH
>>>> variable
>>>> * Apple framework support for static libraries
>>>> * New swig_add_library command in the UseSWIG module
>>>> * New generator expression
$<IF:cond,true-value,false-value>
>>>>
>>>> CMake 3.9 (released July 18th 2017):
>>>> * install(TARGETS) and install(EXPORTS) support for object
libraries,
>>>> which will simplify the compiler-rt build
>>>> * TARGET_OBJECTS generator expression support in
add_custom_command and
>>>> file(GENERATE)
>>>> * $<TARGET_BUNDLE_DIR:tgt> and
$<TARGET_BUNDLE_CONTENT_DIR:tgt>
>>>> generator expressions for Apple bundles
>>>>
>>>> CMake 3.10 (released November 20th 2017):
>>>> * include_guard() command for proper guarding against double
includes
>>>> of CMake scripts
>>>> * An interesting aside is that this is the first verion of
CMake to
>>>> require C++11 to build, which should give a good sense of how
conservative
>>>> they are about compiler requirements
>>>>
>>>> CMake 3.11 (released March 28th 2018):
>>>> * add_library() and add_executable() can be called without
sources as
>>>> long as target_sources() is used later
>>>> * target_compile_{definitions,features,options},
>>>> target_include_directories(), target_sources(), and
target_link_libraries()
>>>> can set the corresponding INTERFACE_* properties on imported
targets
>>>> * COMPILE_DEFINITIONS supports generator expressions
>>>> * COMPILE_OPTIONS source file property added
>>>> * INCLUDE_DIRECTORIES source file property added
>>>> * Interface libraries support custom properites
>>>>
>>>> CMake 3.12 (released July 17th 2018):
>>>> * add_compile_definitions() added to add compile definitions
for
>>>> targets (to avoid the global pollution caused by
add_definitions())
>>>> * cmake_minimum_required() supports a version range to indicate
tested
>>>> CMake versions and set policies accordingly
>>>> * file(TOUCH) and file(TOUCH_NOCREATE) added
>>>> * list(JOIN), list(SUBLIST) and list(TRANSFORM) added
>>>> * string(JOIN) added
>>>> * SHELL: prefix support in target_compile_options to avoid
errant
>>>> deduplication
>>>> * target_link_libraries() supports object libraries and
propagates
>>>> usage requirements
>>>> * EXPORT_PROPERTIES target property to control the target
properties
>>>> exported by export() and install(EXPORT)
>>>> * FindLibXml2 provides imported targets
>>>> * New FindPython, FindPython2, and FindPython3 modules to ease
location
>>>> Python and selecting a specific version
>>>> * Modernization of UseSWIG module
>>>> * New generator expressions $<GENEX_EVAL:...>,
>>>> $<TARGET_GENEX_EVAL:target,...>, $<IN_LIST:...>,
$<TARGET_EXISTS:...> and
>>>> $<TARGET_NAME_IF_EXISTS:...>
>>>> * Compile features support for C++20
>>>>
>>>> CMake 3.13 (released November 20th 2018):
>>>> * cmake -E create_symlink supported on Windows
>>>> * target_link_directories() and target_link_options() commands
to set
>>>> link options instead of awkwardly having to use
target_link_libraries() for
>>>> this purpose
>>>> * UseSWIG can manage INCLUDE_DIRECTORIES for SWIG compilation
>>>>
>>>> CMake 3.14 (released March 14th 2019):
>>>> * file(CREATE_LINK) to create hard or symbolic links
>>>> * if(DEFINED CACHE{VAR}) for checking if a cache variable is
defined
>>>> * $<IN_LIST:...> generator expression correctly handles
empty argument
>>>> * Fixes for object library linking propagation
>>>> * Link options to manage position independent executables added
>>>> automatically
>>>>
>>>> CMake 3.15 (released July 17th 2019):
>>>> * list(PREPEND), list(POP_FRONT) and list(POP_BACK) added
>>>> * New message() types NOTICE, VERBOSE, DEBUG and TRACE
>>>> * string(REPEAT) added
>>>> * MSVC_RUNTIME_LIBRARY target property and
CMAKE_MSVC_RUNTIME_LIBRARY
>>>> variable to select the runtime library type for MSVC
>>>> * $<C_COMPILER_ID:...>, $<CXX_COMPILER_ID:...>,
>>>> $<COMPILE_LANGUAGE:...>, and $<PLATFORM_ID:...>
generator expressions
>>>> support matching one value from a list
>>>> * $<COMPILE_LANG_AND_ID:...> generator expression added
>>>> * $<FILTER:list,INCLUDE|EXCLUDE,regex> generator
expression added
>>>> * $<REMOVE_DUPLICATES:list> generator expression added
>>>> * New $<TARGET_FILE*> generator expressions added:
>>>> $<TARGET_FILE_PREFIX:...>,
$<TARGET_FILE_BASE_NAME:...>,
>>>> $<TARGET_FILE_SUFFIX:...>,
$<TARGET_LINKER_FILE_PREFIX:...>,
>>>> $<TARGET_LINKER_FILE_BASE_NAME:...>,
$<TARGET_LINKER_FILE_SUFFIX:...>,
>>>> $<TARGET_PDB_FILE_BASE_NAME:...>
>>>> * $<TARGET_OBJECTS:...> generator expression supports
executables and
>>>> static, shared, and module libraries
>>>>
>>>> CMake 3.16 (released November 26th 2019):
>>>> * Support for generator expressions in BUILD_RPATH and
INSTALL_RPATH
>>>>
>>>> CMake 3.17 (released March 20th 2020):
>>>> * Ninja Multi-Config generator, which among other things would
greatly
>>>> simplify LLVM_OPTIMIZED_TABLEGEN
>>>> * foreach(ZIP_LISTS) added to iterate multiple lists
simultaneously
>>>> * New message() keywords CHECK_START, CHECK_PASS, and
CHECK_FAIL
>>>> * INSTALL_NAME_DIR supports generator expressions
>>>>
>>>> Our build system is incredibly complex, and many of these
features can
>>>> be used to clean it up and make it much more maintainable. I
would
>>>> personally like us to at least bump up to CMake 3.12. I also do
think it's
>>>> worth establishing a policy and process around upgrading CMake
versions,
>>>> since newer versions keep on adding useful features
(particularly better
>>>> generator expression support), and we want to be able to keep
taking
>>>> advantage of them.
>>>>
>>>> [1]
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html
>>>>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DNovember_136485.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=HtGj57-MndDqyK71vXRwheQXms3WKx9rT-8WAVyTB3c&e=>
>>>> [2]
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html
>>>>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2019-2DNovember_136488.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=atRWn0u_rLa9ITqRSW-W8QvRJN244hhQmDWillcW3gE&s=hHrZYrGk0WStJ3TjjIsXg2NMvVUP-f4woTFtaFlYkG8&e=>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> LLVM Developers mailing list
>>>>
>>>> llvm-dev at lists.llvm.org
>>>>
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200408/3a92aa1a/attachment-0001.html>

A line has to be drawn in the sand somewhere. How many “easy” things are we
going to require the user to do? Today it’s build a specific CMake from source.
What’s next?

Not having to manually track down a bunch of dependencies before building is a
feature. Not having to have an internet connection at build time (if we were to
script the getting of the custom CMake) is a feature. Being able to just call
cmake instead of using some build_llvm.sh that (probably poorly) wraps cmake and
downloads the correct version is a feature. Being able to use CMake that is
distributed with visual studio so that invoking cmake from the developer
powershell just works without fiddling with PATHs is a feature. Not having to
install msys so that I can invoke download_cmake.sh is a feature. Not having to
have the correct version of python (is it 2 or 3?) be on the path in order to
invoke download_cmake.py is a feature. Not having to remember to do
--recurse-submodules on the llvm repo if we include it as a git submodule is a
feature. The list goes on. Yeah, these are all little things, but a bunch of
little things adds up to a huge barrier.

People use Linux distos because by and large they just have all the dependencies
that they need. I know I personally hate installing some open source thing on my
machines when they have some dependency that’s not in the repos. Sure, it may be
easy to build CMake from source. But now I have two CMakes: one that is
automatically updated when I do sudo apt-get upgrade, and one that is just
randomly in some folder that’s probably not on the PATH. I personally would
really appreciate it if we made an attempt to reduce this sort of friction.

Thanks,
   Christopher Tetreault


From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> On Behalf Of Mehdi AMINI via llvm-dev
Sent: Wednesday, April 8, 2020 9:06 AM
To: Louis Dionne <ldionne at apple.com<mailto:ldionne at apple.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake
version



On Wed, Apr 8, 2020 at 9:02 AM Louis Dionne <ldionne at
apple.com<mailto:ldionne at apple.com>> wrote:


On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:



On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>> wrote:
I think it does make a difference how many things we ask new developers to do to
get up and running - because we've asked them to do one thing doesn't
mean it's low-cost to ask them to do another thing.

In this case I see it rather that if we ask them to do one quite big thing
already, we should be OK with what seems like a trivial one.

I strongly agree. I think Mehdi's point can be summarized as (Mehdi, feel
free to correct me):

    It's incredibly trivial to install CMake, so if a user is *already*
required to install a non-default toolchain (which is not so trivial), requiring
them to install a non-default CMake is not increasing the barrier by much.

Thanks, this is my point indeed!

I think it is even slightly stronger than what you wrote since you don't
even need to *install* CMake as it can be built and used directly from the build
directory: it is entirely non-intrusive on the system.

--
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/99b5e8ac/attachment.html>

Hi All,

Throwing a couple of comments in:

Chris's position here has a lot of good points and we want to make sure
we're not raising the barrier too high. I definitely want to be able to
push ahead with our versions of tools; being able to update quickly is one
of the hallmarks of the llvm project. That said, binary packages that can
be updated are a minimal first step IMO. I'd really like to not build
anything from source :) It seems like there are binaries available for
cmake for all of our current platforms, but the windows use case that he
brings is definitely a significant one. Can we perhaps reach out and find
out the likelihood of a reasonably soonish update there? Linux distros are
probably less of a problem - while we all can't use ppas we should be able
to do something, similarly with osx.

Thoughts?

-eric



On Wed, Apr 8, 2020 at 9:53 AM Chris Tetreault via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> A line has to be drawn in the sand somewhere. How many “easy” things are
> we going to require the user to do? Today it’s build a specific CMake from
> source. What’s next?
>
>
>
> Not having to manually track down a bunch of dependencies before building
> is a feature. Not having to have an internet connection at build time (if
> we were to script the getting of the custom CMake) is a feature. Being able
> to just call cmake instead of using some build_llvm.sh that (probably
> poorly) wraps cmake and downloads the correct version is a feature. Being
> able to use CMake that is distributed with visual studio so that invoking
> cmake from the developer powershell just works without fiddling with PATHs
> is a feature. Not having to install msys so that I can invoke
> download_cmake.sh is a feature. Not having to have the correct version of
> python (is it 2 or 3?) be on the path in order to invoke download_cmake.py
> is a feature. Not having to remember to do --recurse-submodules on the llvm
> repo if we include it as a git submodule is a feature. The list goes on.
> Yeah, these are all little things, but a bunch of little things adds up to
> a huge barrier.
>
>
>
> People use Linux distos because by and large they just have all the
> dependencies that they need. I know I personally hate installing some open
> source thing on my machines when they have some dependency that’s not in
> the repos. Sure, it may be easy to build CMake from source. But now I have
> two CMakes: one that is automatically updated when I do sudo apt-get
> upgrade, and one that is just randomly in some folder that’s probably not
> on the PATH. I personally would really appreciate it if we made an attempt
> to reduce this sort of friction.
>
>
>
> Thanks,
>
>    Christopher Tetreault
>
>
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Mehdi
> AMINI via llvm-dev
> *Sent:* Wednesday, April 8, 2020 9:06 AM
> *To:* Louis Dionne <ldionne at apple.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake
> version
>
>
>
>
>
>
>
> On Wed, Apr 8, 2020 at 9:02 AM Louis Dionne <ldionne at apple.com>
wrote:
>
>
>
>
>
> On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
>
>
>
>
> On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dblaikie at gmail.com>
wrote:
>
> I think it does make a difference how many things we ask new developers to
> do to get up and running - because we've asked them to do one thing
doesn't
> mean it's low-cost to ask them to do another thing.
>
>
>
> In this case I see it rather that if we ask them to do one quite big thing
> already, we should be OK with what seems like a trivial one.
>
>
>
> I strongly agree. I think Mehdi's point can be summarized as (Mehdi,
feel
> free to correct me):
>
>
>
>     It's incredibly trivial to install CMake, so if a user is *already*
> required to install a non-default toolchain (which is not so trivial),
> requiring them to install a non-default CMake is not increasing the barrier
> by much.
>
>
>
> Thanks, this is my point indeed!
>
>
>
> I think it is even slightly stronger than what you wrote since you
don't
> even need to *install* CMake as it can be built and used directly from the
> build directory: it is entirely non-intrusive on the system.
>
>
>
> --
>
> Mehdi
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200408/180ebdc9/attachment.html>