llvm dev - Jun 2016 - [RFC] LLVM Directory Structure Changes (was Re: [PATCH] D20992: [CMake] Add LLVM runtimes directory)

Moving to llvm-dev (I think this has gone a bit further than a patch review
discussion)

In hindsight I probably should have explained more of my thinking on this with
the patch, or done an RFC on llvm-dev to start with. I’l do that now, and answer
the questions along the way. I sent a separate email discussing Justin’s patch
review feedback.

In the build system today there is no strong distinction between ‘projects’ and
‘tools’. There are a few subtle differences, but I’m not sure any of them really
matter. The differences are:

(1) The projects directory is always configured, tools can be disabled using
LLVM_INCLUDE_TOOLS=Off (projects and tools can both be individually disabled
too)
(2) Projects are configured before tools, so tools can rely on targets being
created for projects (we don’t really use this, and anywhere we are is probably
a bug)
(3) Some projects have special handling. For example test-suite isn’t actually
treated as a project, it has special handling in LLVM/CMakeLists.txt:727, and
Compiler-RT is handled by clang if you set LLVM_BUILD_EXTERNAL_COMPILER_RT=On.

With this in mind I was thinking about the general usability of our build
system. The distinction between a project and a tool is not very clear. At a
high level I see three different use cases that are covered by our current
projects & tools directories.

(1) Projects that are configured with LLVM
(2) Runtime projects that should be configured using the just-built tools
(3) The LLVM test-suite, which is really just external tests that should be
configured and run with the just-built tools

My proposal is that we make the tools subdirectory the *only* place for projects
that fall into category 1. I don’t think there is any technical reason to drop
an in-tree project into projects over tools today, and I think we migrating
people who are doing that away from it should be easy.

Second I want to add a “runtimes” directory to LLVM to cover case 2 (see
D20992). The idea behind this is to use common code in LLVM to support building
runtimes. This will allow the full LLVM toolchain to be visible during
configuration. I will abstract this functionality into an installed CMake module
so that Clang can use it for out-of-tree clang builds.

Lastly we need to give the test-suite a new home. I’m not super concerned with
where we do that. It could be under tests, it could just be at the root of the
LLVM directory. I don’t think it matters too much because it is a one-off.
Thoughts welcome.

My proposed patch makes the runtimes directory work for Compiler-RT, but it
doesn’t yet handle libcxxabi, libcxx and libunwind. There is some special case
handling between libcxxabi and libcxx that will need to be handled to make the
dependencies work between the two, and I still need to work that out.

If we want to go with this proposal I envision the transition being
multi-staged:

(1) Adding the new functionality, getting it up and fully working for all
runtime projects - this will involve changes to runtime projects
(2) Work with bot maintainers to migrate bots, and fix any issues that come up
(3) Add support for a new secondary location for the test-suite
(4) Set a date for removing the projects directory, post patches including
updated documentation
(5) Remove the projects directory entirely

Thoughts?
-Chris
> On Jun 8, 2016, at 6:59 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 
> On Wed, Jun 8, 2016 at 4:39 PM Justin Bogner via llvm-commits
<llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org>> wrote:
> Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>>
writes:
> > beanz created this revision.
> > beanz added reviewers: chandlerc, bogner.
> > beanz added a subscriber: llvm-commits.
> >
> > There are a few LLVM projects that produce runtime libraries. Ideally
> > runtime libraries should be built differently than other projects,
> > specifically they should be built using the just-built toolchain.
> >
> > There is support for building compiler-rt in this way from the clang
> > build. Moving this logic into the LLVM build is interesting because it
> > provides a simpler way to extend the just-built toolchain to include
> > LLD and the LLVM object file tools.
> >
> > Once this functionality is better fleshed out and tested we’ll want to
> > encapsulate it in a module that can be used for clang standalone
> > builds, and we’ll want to make it the default way to build
compiler-rt.
> >
> > With this patch applied there is no immediate change in the build.
> > Moving compiler-rt out from llvm/projects into llvm/runtimes enables
> > the functionality.
> 
> This seems reasonable, but I am a little worried about how transitioning
> to the new system will work. Will everyone have to move their
> compiler-rt checkout? Will we continue to support compiler-rt in either
> place? Both of these are workable, but neither is great. Thoughts?
> 
> I share your concerns, but I also kind of like the direction this is going.
> 
> But there is a higher-level meta-point: do we want to keep the
'projects' directory *at all*.
> 
> Every single resident of it I can think of except for the test-suite is
either dead (dragonegg) or a runtime library.
> 
> I think we should either have all the build-integrated projects in a single
'projects' directory (including LLD and Clang), or we should have none
of them and use more domain relevant organization (today "tools",
you're adding "runtimes", maybe we move the test-suite to go under
one of the test directories).
> 
> I think we should have a consistent plan here before moving stuff. But once
we have it, I think we shouldn't be afraid of re-organizing stuff to make
more sense, and just work to get folks to update their checkouts.
> 
> -Chandler
>  
> 
> > This code has a few improvements over the method provided by
> > LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is
> > always invoked, so changes to compiler-rt source files will get built
> > properly, so this patch can be used for iterative development with
> > just-built tools.
> >
> > http://reviews.llvm.org/D20992 <http://reviews.llvm.org/D20992>
> >
> > Files:
> >   CMakeLists.txt
> >   cmake/modules/LLVMExternalProjectUtils.cmake
> >   runtimes/CMakeLists.txt
> >
> > Index: runtimes/CMakeLists.txt
> > ==================================================================>
> --- /dev/null
> > +++ runtimes/CMakeLists.txt
> > @@ -0,0 +1,16 @@
> > +include(LLVMExternalProjectUtils)
> > +
> > +# Discover the projects that use CMake in the subdirectories.
> > +# Note that explicit cmake invocation is required every time a new
project is
> > +# added or removed.
> > +
> > +add_custom_target(runtimes)
> > +
> > +file(GLOB entries *)
> > +foreach(entry ${entries})
> > +  if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
> > +    get_filename_component(projName ${entry} NAME)
> > +    llvm_ExternalProject_Add(${projName} ${entry} USE_TOOLCHAIN)
> > +    add_dependencies(runtimes ${projName})
> > +  endif()
> > +endforeach(entry)
> > Index: cmake/modules/LLVMExternalProjectUtils.cmake
> > ==================================================================>
> --- cmake/modules/LLVMExternalProjectUtils.cmake
> > +++ cmake/modules/LLVMExternalProjectUtils.cmake
> > @@ -29,7 +29,8 @@
> >  #     Extra targets in the subproject to generate targets for
> >  #   )
> >  function(llvm_ExternalProject_Add name source_dir)
> > -  cmake_parse_arguments(ARG
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL"
> > +  cmake_parse_arguments(ARG
> > +   
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL;ALWAYS_CLEAN"
> >      "SOURCE_DIR"
> >     
"CMAKE_ARGS;TOOLCHAIN_TOOLS;RUNTIME_LIBRARIES;DEPENDS;EXTRA_TARGETS"
${ARGN})
> >    canonicalize_tool_name(${name} nameCanon)
> > @@ -52,6 +53,10 @@
> >      endif()
> >    endforeach()
> >
> > +  if(ARG_ALWAYS_CLEAN)
> > +    set(always_clean clean)
> > +  endif()
> > +
> >    list(FIND TOOLCHAIN_TOOLS clang FOUND_CLANG)
> >    if(FOUND_CLANG GREATER -1)
> >      set(CLANG_IN_TOOLCHAIN On)
> > @@ -135,6 +140,14 @@
> >      CMAKE_ARGS ${${nameCanon}_CMAKE_ARGS}
> >                 ${compiler_args}
> >                 -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
> > +              
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
> > +              
-DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_OUTPUT_INTDIR}
> > +              
-DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
> > +               -DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
> > +               -DLLVM_ENABLE_WERROR=${LLVM_ENABLE_WERROR}
> > +               -DPACKAGE_VERSION=${PACKAGE_VERSION}
> > +               -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
> > +               -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
> 
> How did you decide which variables need to be passed through like this?
> The set seems somewhat arbitrary, but I may be missing something
> obvious.
> 
> >                 ${ARG_CMAKE_ARGS}
> >                 ${PASSTHROUGH_VARIABLES}
> >      INSTALL_COMMAND ""
> > @@ -152,7 +165,7 @@
> >      ExternalProject_Add_Step(${name} force-rebuild
> >        COMMAND ${run_build}
> >        COMMENT "Forcing rebuild of ${name}"
> > -      DEPENDEES configure clean
> > +      DEPENDEES configure ${always_clean}
> 
> I'm not sure I understand what this does. If I had to guess I'd say
that
> when ALWAYS_CLEAN is passed the rebuild of the external project always
> invokes clean first, but if it's not passed we'll just invoke the
> external build and allow it to be incremental if appropriate. Is that
> right?
> 
> >        DEPENDS ${ALWAYS_REBUILD} ${ARG_DEPENDS} ${TOOLCHAIN_BINS}
> >        ${cmake_3_4_USES_TERMINAL} )
> >    endif()
> > Index: CMakeLists.txt
> > ==================================================================>
> --- CMakeLists.txt
> > +++ CMakeLists.txt
> > @@ -720,6 +720,8 @@
> >    add_subdirectory(tools)
> >  endif()
> >
> > +add_subdirectory(runtimes)
> > +
> >  if( LLVM_INCLUDE_EXAMPLES )
> >    add_subdirectory(examples)
> >  endif()
> > @@ -730,7 +732,8 @@
> >      llvm_ExternalProject_Add(test-suite
${LLVM_MAIN_SRC_DIR}/projects/test-suite
> >        USE_TOOLCHAIN
> >        EXCLUDE_FROM_ALL
> > -      NO_INSTALL)
> > +      NO_INSTALL
> > +      ALWAYS_CLEAN)
> >    endif()
> >    add_subdirectory(test)
> >    add_subdirectory(unittests)
> >
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160609/fa1765d3/attachment-0001.html>

----- Original Message -----
> From: "Chris Bieneman via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "Chandler Carruth" <chandlerc at gmail.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Thursday, June 9, 2016 12:20:36 PM
> Subject: [llvm-dev] [RFC] LLVM Directory Structure Changes (was Re: [PATCH]
D20992: [CMake] Add LLVM runtimes
> directory)
> 
> 
> 
> Moving to llvm-dev (I think this has gone a bit further than a patch
> review discussion)
> 
> 
> In hindsight I probably should have explained more of my thinking on
> this with the patch, or done an RFC on llvm-dev to start with. I’l
> do that now, and answer the questions along the way. I sent a
> separate email discussing Justin’s patch review feedback.
> 
> 
> In the build system today there is no strong distinction between
> ‘projects’ and ‘tools’. There are a few subtle differences, but I’m
> not sure any of them really matter. The differences are:
> 
> 
> (1) The projects directory is always configured, tools can be
> disabled using LLVM_INCLUDE_TOOLS=Off (projects and tools can both
> be individually disabled too)
> (2) Projects are configured before tools, so tools can rely on
> targets being created for projects (we don’t really use this, and
> anywhere we are is probably a bug)
> (3) Some projects have special handling. For example test-suite isn’t
> actually treated as a project, it has special handling in
> LLVM/CMakeLists.txt:727, and Compiler-RT is handled by clang if you
> set LLVM_BUILD_EXTERNAL_COMPILER_RT=On.
> 
> 
> With this in mind I was thinking about the general usability of our
> build system. The distinction between a project and a tool is not
> very clear. At a high level I see three different use cases that are
> covered by our current projects & tools directories.
> 
> 
> (1) Projects that are configured with LLVM
> (2) Runtime projects that should be configured using the just-built
> tools
> (3) The LLVM test-suite, which is really just external tests that
> should be configured and run with the just-built tools
> 
> 
> My proposal is that we make the tools subdirectory the *only* place
> for projects that fall into category 1. I don’t think there is any
> technical reason to drop an in-tree project into projects over tools
> today, and I think we migrating people who are doing that away from
> it should be easy.
> 
> 
> Second I want to add a “runtimes” directory to LLVM to cover case 2
> (see D20992). The idea behind this is to use common code in LLVM to
> support building runtimes. This will allow the full LLVM toolchain
> to be visible during configuration. I will abstract this
> functionality into an installed CMake module so that Clang can use
> it for out-of-tree clang builds.
> 
> 
> Lastly we need to give the test-suite a new home. I’m not super
> concerned with where we do that. It could be under tests, it could
> just be at the root of the LLVM directory. I don’t think it matters
> too much because it is a one-off. Thoughts welcome.
This all makes sense to me. It matches my mental model that tools get compiled
with the 'host' compiler and the runtimes need to get cross-compiled.
Putting the test-suite at the top-level could work, we already have a
'test' and 'unittests' directory. Maybe, however, unit tests
should live under tests?

 -Hal
 
> My proposed patch makes the runtimes directory work for Compiler-RT,
> but it doesn’t yet handle libcxxabi, libcxx and libunwind. There is
> some special case handling between libcxxabi and libcxx that will
> need to be handled to make the dependencies work between the two,
> and I still need to work that out.
> 
> 
> If we want to go with this proposal I envision the transition being
> multi-staged:
> 
> 
> (1) Adding the new functionality, getting it up and fully working for
> all runtime projects - this will involve changes to runtime projects
> (2) Work with bot maintainers to migrate bots, and fix any issues
> that come up
> (3) Add support for a new secondary location for the test-suite
> (4) Set a date for removing the projects directory, post patches
> including updated documentation
> (5) Remove the projects directory entirely
> 
> 
> Thoughts?
> -Chris
> 
> 
> 
> 
> 
> On Jun 8, 2016, at 6:59 PM, Chandler Carruth < chandlerc at gmail.com
>
> wrote:
> 
> 
> 
> 
> On Wed, Jun 8, 2016 at 4:39 PM Justin Bogner via llvm-commits <
> llvm-commits at lists.llvm.org > wrote:
> 
> 
> Chris Bieneman < beanz at apple.com > writes:
> > beanz created this revision.
> > beanz added reviewers: chandlerc, bogner.
> > beanz added a subscriber: llvm-commits.
> > 
> > There are a few LLVM projects that produce runtime libraries.
> > Ideally
> > runtime libraries should be built differently than other projects,
> > specifically they should be built using the just-built toolchain.
> > 
> > There is support for building compiler-rt in this way from the
> > clang
> > build. Moving this logic into the LLVM build is interesting because
> > it
> > provides a simpler way to extend the just-built toolchain to
> > include
> > LLD and the LLVM object file tools.
> > 
> > Once this functionality is better fleshed out and tested we’ll want
> > to
> > encapsulate it in a module that can be used for clang standalone
> > builds, and we’ll want to make it the default way to build
> > compiler-rt.
> > 
> > With this patch applied there is no immediate change in the build.
> > Moving compiler-rt out from llvm/projects into llvm/runtimes
> > enables
> > the functionality.
> 
> This seems reasonable, but I am a little worried about how
> transitioning
> to the new system will work. Will everyone have to move their
> compiler-rt checkout? Will we continue to support compiler-rt in
> either
> place? Both of these are workable, but neither is great. Thoughts?
> 
> 
> 
> I share your concerns, but I also kind of like the direction this is
> going.
> 
> 
> But there is a higher-level meta-point: do we want to keep the
> 'projects' directory *at all*.
> 
> 
> Every single resident of it I can think of except for the test-suite
> is either dead (dragonegg) or a runtime library.
> 
> 
> I think we should either have all the build-integrated projects in a
> single 'projects' directory (including LLD and Clang), or we should
> have none of them and use more domain relevant organization (today
> "tools", you're adding "runtimes", maybe we move
the test-suite to
> go under one of the test directories).
> 
> 
> I think we should have a consistent plan here before moving stuff.
> But once we have it, I think we shouldn't be afraid of re-organizing
> stuff to make more sense, and just work to get folks to update their
> checkouts.
> 
> 
> -Chandler
> 
> 
> 
> > This code has a few improvements over the method provided by
> > LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command
> > is
> > always invoked, so changes to compiler-rt source files will get
> > built
> > properly, so this patch can be used for iterative development with
> > just-built tools.
> > 
> > http://reviews.llvm.org/D20992
> > 
> > Files:
> > CMakeLists.txt
> > cmake/modules/LLVMExternalProjectUtils.cmake
> > runtimes/CMakeLists.txt
> > 
> > Index: runtimes/CMakeLists.txt
> > ==================================================================>
> --- /dev/null
> > +++ runtimes/CMakeLists.txt
> > @@ -0,0 +1,16 @@
> > +include(LLVMExternalProjectUtils)
> > +
> > +# Discover the projects that use CMake in the subdirectories.
> > +# Note that explicit cmake invocation is required every time a new
> > project is
> > +# added or removed.
> > +
> > +add_custom_target(runtimes)
> > +
> > +file(GLOB entries *)
> > +foreach(entry ${entries})
> > + if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
> > + get_filename_component(projName ${entry} NAME)
> > + llvm_ExternalProject_Add(${projName} ${entry} USE_TOOLCHAIN)
> > + add_dependencies(runtimes ${projName})
> > + endif()
> > +endforeach(entry)
> > Index: cmake/modules/LLVMExternalProjectUtils.cmake
> > ==================================================================>
> --- cmake/modules/LLVMExternalProjectUtils.cmake
> > +++ cmake/modules/LLVMExternalProjectUtils.cmake
> > @@ -29,7 +29,8 @@
> > # Extra targets in the subproject to generate targets for
> > # )
> > function(llvm_ExternalProject_Add name source_dir)
> > - cmake_parse_arguments(ARG
> > "USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL"
> > + cmake_parse_arguments(ARG
> > + "USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL;ALWAYS_CLEAN"
> > "SOURCE_DIR"
> >
"CMAKE_ARGS;TOOLCHAIN_TOOLS;RUNTIME_LIBRARIES;DEPENDS;EXTRA_TARGETS"
> > ${ARGN})
> > canonicalize_tool_name(${name} nameCanon)
> > @@ -52,6 +53,10 @@
> > endif()
> > endforeach()
> > 
> > + if(ARG_ALWAYS_CLEAN)
> > + set(always_clean clean)
> > + endif()
> > +
> > list(FIND TOOLCHAIN_TOOLS clang FOUND_CLANG)
> > if(FOUND_CLANG GREATER -1)
> > set(CLANG_IN_TOOLCHAIN On)
> > @@ -135,6 +140,14 @@
> > CMAKE_ARGS ${${nameCanon}_CMAKE_ARGS}
> > ${compiler_args}
> > -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
> > + -DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
> > + -DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_OUTPUT_INTDIR}
> > + -DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
> > + -DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
> > + -DLLVM_ENABLE_WERROR=${LLVM_ENABLE_WERROR}
> > + -DPACKAGE_VERSION=${PACKAGE_VERSION}
> > + -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
> > + -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
> 
> How did you decide which variables need to be passed through like
> this?
> The set seems somewhat arbitrary, but I may be missing something
> obvious.
> 
> > ${ARG_CMAKE_ARGS}
> > ${PASSTHROUGH_VARIABLES}
> > INSTALL_COMMAND ""
> > @@ -152,7 +165,7 @@
> > ExternalProject_Add_Step(${name} force-rebuild
> > COMMAND ${run_build}
> > COMMENT "Forcing rebuild of ${name}"
> > - DEPENDEES configure clean
> > + DEPENDEES configure ${always_clean}
> 
> I'm not sure I understand what this does. If I had to guess I'd say
> that
> when ALWAYS_CLEAN is passed the rebuild of the external project
> always
> invokes clean first, but if it's not passed we'll just invoke the
> external build and allow it to be incremental if appropriate. Is that
> right?
> 
> > DEPENDS ${ALWAYS_REBUILD} ${ARG_DEPENDS} ${TOOLCHAIN_BINS}
> > ${cmake_3_4_USES_TERMINAL} )
> > endif()
> > Index: CMakeLists.txt
> > ==================================================================>
> --- CMakeLists.txt
> > +++ CMakeLists.txt
> > @@ -720,6 +720,8 @@
> > add_subdirectory(tools)
> > endif()
> > 
> > +add_subdirectory(runtimes)
> > +
> > if( LLVM_INCLUDE_EXAMPLES )
> > add_subdirectory(examples)
> > endif()
> > @@ -730,7 +732,8 @@
> > llvm_ExternalProject_Add(test-suite
> > ${LLVM_MAIN_SRC_DIR}/projects/test-suite
> > USE_TOOLCHAIN
> > EXCLUDE_FROM_ALL
> > - NO_INSTALL)
> > + NO_INSTALL
> > + ALWAYS_CLEAN)
> > endif()
> > add_subdirectory(test)
> > add_subdirectory(unittests)
> > 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Chris Bieneman <beanz at apple.com> writes:
> Moving to llvm-dev (I think this has gone a bit further than a patch
> review discussion)
>
> In hindsight I probably should have explained more of my thinking on
> this with the patch, or done an RFC on llvm-dev to start with. I’l do
> that now, and answer the questions along the way. I sent a separate
> email discussing Justin’s patch review feedback.
>
> In the build system today there is no strong distinction between
> ‘projects’ and ‘tools’. There are a few subtle differences, but I’m
> not sure any of them really matter. The differences are:
>
> (1) The projects directory is always configured, tools can be disabled
> using LLVM_INCLUDE_TOOLS=Off (projects and tools can both be
> individually disabled too)
> (2) Projects are configured before tools, so tools can rely on targets
> being created for projects (we don’t really use this, and anywhere we
> are is probably a bug)
> (3) Some projects have special handling. For example test-suite isn’t
> actually treated as a project, it has special handling in
> LLVM/CMakeLists.txt:727, and Compiler-RT is handled by clang if you
> set LLVM_BUILD_EXTERNAL_COMPILER_RT=On.
>
> With this in mind I was thinking about the general usability of our
> build system. The distinction between a project and a tool is not very
> clear. At a high level I see three different use cases that are
> covered by our current projects & tools directories.
>
> (1) Projects that are configured with LLVM
> (2) Runtime projects that should be configured using the just-built tools
> (3) The LLVM test-suite, which is really just external tests that
> should be configured and run with the just-built tools
>
> My proposal is that we make the tools subdirectory the *only* place
> for projects that fall into category 1. I don’t think there is any
> technical reason to drop an in-tree project into projects over tools
> today, and I think we migrating people who are doing that away from it
> should be easy.
>
> Second I want to add a “runtimes” directory to LLVM to cover case 2
> (see D20992). The idea behind this is to use common code in LLVM to
> support building runtimes. This will allow the full LLVM toolchain to
> be visible during configuration. I will abstract this functionality
> into an installed CMake module so that Clang can use it for
> out-of-tree clang builds.
>
> Lastly we need to give the test-suite a new home. I’m not super
> concerned with where we do that. It could be under tests, it could
> just be at the root of the LLVM directory. I don’t think it matters
> too much because it is a one-off. Thoughts welcome.
This all seems pretty sensible. Should we also use the opportunity to
split compiler-rt's builtins and profiling/sanitizer/etc runtimes, since
we'll be moving things around anyway?

Some place like test/external or test/integration would probably make
sense. It could potentially also be used for other optional tests like
debuginfo-tests, which are currently somewhat awkwardly checked out into
clang's tests.
> My proposed patch makes the runtimes directory work for Compiler-RT,
> but it doesn’t yet handle libcxxabi, libcxx and libunwind. There is
> some special case handling between libcxxabi and libcxx that will need
> to be handled to make the dependencies work between the two, and I
> still need to work that out.
>
> If we want to go with this proposal I envision the transition being
> multi-staged:
>
> (1) Adding the new functionality, getting it up and fully working for
> all runtime projects - this will involve changes to runtime projects
> (2) Work with bot maintainers to migrate bots, and fix any issues that come
up
> (3) Add support for a new secondary location for the test-suite
> (4) Set a date for removing the projects directory, post patches
> including updated documentation
Sure, but we might as well update the documentation earlier (in step 1)
- as soon as compiler-rt can live in runtimes it makes sense to tell
people to put it there, even if we still have legacy logic to make it
continue to work out of projects as well.
> (5) Remove the projects directory entirely
>
> Thoughts?
> -Chris
>
>> On Jun 8, 2016, at 6:59 PM, Chandler Carruth <chandlerc at
gmail.com> wrote:
>> 
>> On Wed, Jun 8, 2016 at 4:39 PM Justin Bogner via llvm-commits
>> <llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org>>
>> wrote:
>> Chris Bieneman <beanz at apple.com <mailto:beanz at
apple.com>> writes:
>> > beanz created this revision.
>> > beanz added reviewers: chandlerc, bogner.
>> > beanz added a subscriber: llvm-commits.
>> >
>> > There are a few LLVM projects that produce runtime libraries.
Ideally
>> > runtime libraries should be built differently than other projects,
>> > specifically they should be built using the just-built toolchain.
>> >
>> > There is support for building compiler-rt in this way from the
clang
>> > build. Moving this logic into the LLVM build is interesting
because it
>> > provides a simpler way to extend the just-built toolchain to
include
>> > LLD and the LLVM object file tools.
>> >
>> > Once this functionality is better fleshed out and tested we’ll
want to
>> > encapsulate it in a module that can be used for clang standalone
>> > builds, and we’ll want to make it the default way to build
compiler-rt.
>> >
>> > With this patch applied there is no immediate change in the build.
>> > Moving compiler-rt out from llvm/projects into llvm/runtimes
enables
>> > the functionality.
>> 
>> This seems reasonable, but I am a little worried about how
transitioning
>> to the new system will work. Will everyone have to move their
>> compiler-rt checkout? Will we continue to support compiler-rt in either
>> place? Both of these are workable, but neither is great. Thoughts?
>> 
>> I share your concerns, but I also kind of like the direction this is
going.
>> 
>> But there is a higher-level meta-point: do we want to keep the
>> 'projects' directory *at all*.
>> 
>> Every single resident of it I can think of except for the test-suite
>> is either dead (dragonegg) or a runtime library.
>> 
>> I think we should either have all the build-integrated projects in a
>> single 'projects' directory (including LLD and Clang), or we
should
>> have none of them and use more domain relevant organization (today
>> "tools", you're adding "runtimes", maybe we
move the test-suite to
>> go under one of the test directories).
>> 
>> I think we should have a consistent plan here before moving
>> stuff. But once we have it, I think we shouldn't be afraid of
>> re-organizing stuff to make more sense, and just work to get folks
>> to update their checkouts.
>> 
>> -Chandler
>>  
>> 
>> > This code has a few improvements over the method provided by
>> > LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja
command is
>> > always invoked, so changes to compiler-rt source files will get
built
>> > properly, so this patch can be used for iterative development with
>> > just-built tools.
>> >
>> > http://reviews.llvm.org/D20992
<http://reviews.llvm.org/D20992>
>> >
>> > Files:
>> >   CMakeLists.txt
>> >   cmake/modules/LLVMExternalProjectUtils.cmake
>> >   runtimes/CMakeLists.txt
>> >
>> > Index: runtimes/CMakeLists.txt
>> >
==================================================================>> >
--- /dev/null
>> > +++ runtimes/CMakeLists.txt
>> > @@ -0,0 +1,16 @@
>> > +include(LLVMExternalProjectUtils)
>> > +
>> > +# Discover the projects that use CMake in the subdirectories.
>> > +# Note that explicit cmake invocation is required every time a
new project is
>> > +# added or removed.
>> > +
>> > +add_custom_target(runtimes)
>> > +
>> > +file(GLOB entries *)
>> > +foreach(entry ${entries})
>> > +  if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
>> > +    get_filename_component(projName ${entry} NAME)
>> > +    llvm_ExternalProject_Add(${projName} ${entry} USE_TOOLCHAIN)
>> > +    add_dependencies(runtimes ${projName})
>> > +  endif()
>> > +endforeach(entry)
>> > Index: cmake/modules/LLVMExternalProjectUtils.cmake
>> >
==================================================================>> >
--- cmake/modules/LLVMExternalProjectUtils.cmake
>> > +++ cmake/modules/LLVMExternalProjectUtils.cmake
>> > @@ -29,7 +29,8 @@
>> >  #     Extra targets in the subproject to generate targets for
>> >  #   )
>> >  function(llvm_ExternalProject_Add name source_dir)
>> > -  cmake_parse_arguments(ARG
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL"
>> > +  cmake_parse_arguments(ARG
>> > +   
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL;ALWAYS_CLEAN"
>> >      "SOURCE_DIR"
>> >     
"CMAKE_ARGS;TOOLCHAIN_TOOLS;RUNTIME_LIBRARIES;DEPENDS;EXTRA_TARGETS"
${ARGN})
>> >    canonicalize_tool_name(${name} nameCanon)
>> > @@ -52,6 +53,10 @@
>> >      endif()
>> >    endforeach()
>> >
>> > +  if(ARG_ALWAYS_CLEAN)
>> > +    set(always_clean clean)
>> > +  endif()
>> > +
>> >    list(FIND TOOLCHAIN_TOOLS clang FOUND_CLANG)
>> >    if(FOUND_CLANG GREATER -1)
>> >      set(CLANG_IN_TOOLCHAIN On)
>> > @@ -135,6 +140,14 @@
>> >      CMAKE_ARGS ${${nameCanon}_CMAKE_ARGS}
>> >                 ${compiler_args}
>> >                 -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
>> > +              
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
>> > +              
-DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_OUTPUT_INTDIR}
>> > +              
-DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
>> > +               -DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
>> > +               -DLLVM_ENABLE_WERROR=${LLVM_ENABLE_WERROR}
>> > +               -DPACKAGE_VERSION=${PACKAGE_VERSION}
>> > +               -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
>> > +               -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
>> 
>> How did you decide which variables need to be passed through like this?
>> The set seems somewhat arbitrary, but I may be missing something
>> obvious.
>> 
>> >                 ${ARG_CMAKE_ARGS}
>> >                 ${PASSTHROUGH_VARIABLES}
>> >      INSTALL_COMMAND ""
>> > @@ -152,7 +165,7 @@
>> >      ExternalProject_Add_Step(${name} force-rebuild
>> >        COMMAND ${run_build}
>> >        COMMENT "Forcing rebuild of ${name}"
>> > -      DEPENDEES configure clean
>> > +      DEPENDEES configure ${always_clean}
>> 
>> I'm not sure I understand what this does. If I had to guess I'd
say that
>> when ALWAYS_CLEAN is passed the rebuild of the external project always
>> invokes clean first, but if it's not passed we'll just invoke
the
>> external build and allow it to be incremental if appropriate. Is that
>> right?
>> 
>> >        DEPENDS ${ALWAYS_REBUILD} ${ARG_DEPENDS} ${TOOLCHAIN_BINS}
>> >        ${cmake_3_4_USES_TERMINAL} )
>> >    endif()
>> > Index: CMakeLists.txt
>> >
==================================================================>> >
--- CMakeLists.txt
>> > +++ CMakeLists.txt
>> > @@ -720,6 +720,8 @@
>> >    add_subdirectory(tools)
>> >  endif()
>> >
>> > +add_subdirectory(runtimes)
>> > +
>> >  if( LLVM_INCLUDE_EXAMPLES )
>> >    add_subdirectory(examples)
>> >  endif()
>> > @@ -730,7 +732,8 @@
>> >      llvm_ExternalProject_Add(test-suite
${LLVM_MAIN_SRC_DIR}/projects/test-suite
>> >        USE_TOOLCHAIN
>> >        EXCLUDE_FROM_ALL
>> > -      NO_INSTALL)
>> > +      NO_INSTALL
>> > +      ALWAYS_CLEAN)
>> >    endif()
>> >    add_subdirectory(test)
>> >    add_subdirectory(unittests)
>> >
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>

On 9 June 2016 at 18:49, Justin Bogner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> This all seems pretty sensible. Should we also use the opportunity to
> split compiler-rt's builtins and profiling/sanitizer/etc runtimes,
since
> we'll be moving things around anyway?
Also be good to make Compiler-RT and libc++ cross-compile for multiple
targets... :/

While that may be another battle entirely, it'd be good to keep that
in mind if we do split them up to pieces.

cheers,
--renato

On Jun 9, 2016, at 12:20 PM, Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> My proposal is that we make the tools subdirectory the *only* place for
projects that fall into category 1.
+1
> 
> Second I want to add a “runtimes” directory to LLVM to cover case 2 (see
D20992).
+1
> 
> If we want to go with this proposal I envision the transition being
multi-staged:
> 
> (1) Adding the new functionality, getting it up and fully working for all
runtime projects - this will involve changes to runtime projects
> (2) Work with bot maintainers to migrate bots, and fix any issues that come
up
> (3) Add support for a new secondary location for the test-suite
> (4) Set a date for removing the projects directory, post patches including
updated documentation
> (5) Remove the projects directory entirely
This is pretty intrusive … We (internally) probably have a lot of individual
people and scripts doing things in various ways that will need adjustment.   
I’d vote for a pretty liberal window on the timing of the removal step.

However, I think it’s clearly worthwhile.

Jim Rowan
jmr at codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On Jun 9, 2016, at 12:49 PM, Justin Bogner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Should we also use the opportunity to
> split compiler-rt's builtins and profiling/sanitizer/etc runtimes,
since
> we'll be moving things around anyway?
+1


Jim Rowan
jmr at codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

> On Jun 9, 2016, at 11:10 AM, Jim Rowan <jmr at codeaurora.org> wrote:
> 
> 
> On Jun 9, 2016, at 12:20 PM, Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>> 
>> My proposal is that we make the tools subdirectory the *only* place for
projects that fall into category 1.
> 
> +1
> 
>> 
>> Second I want to add a “runtimes” directory to LLVM to cover case 2
(see D20992).
> 
> +1
> 
>> 
>> If we want to go with this proposal I envision the transition being
multi-staged:
>> 
>> (1) Adding the new functionality, getting it up and fully working for
all runtime projects - this will involve changes to runtime projects
>> (2) Work with bot maintainers to migrate bots, and fix any issues that
come up
>> (3) Add support for a new secondary location for the test-suite
>> (4) Set a date for removing the projects directory, post patches
including updated documentation
>> (5) Remove the projects directory entirely
> 
> This is pretty intrusive … We (internally) probably have a lot of
individual people and scripts doing things in various ways that will need
adjustment.    I’d vote for a pretty liberal window on the timing of the removal
step.
Agreed completely. I think removing the projects directory is not something we
can do on a whim because people rely on it extensively.

-Chris
> 
> However, I think it’s clearly worthwhile.
> 
> Jim Rowan
> jmr at codeaurora.org
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by the Linux Foundation
> 
> 
>

> On Jun 9, 2016, at 10:49 AM, Justin Bogner <mail at justinbogner.com>
wrote:
> 
> Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>>
writes:
>> Moving to llvm-dev (I think this has gone a bit further than a patch
>> review discussion)
>> 
>> In hindsight I probably should have explained more of my thinking on
>> this with the patch, or done an RFC on llvm-dev to start with. I’l do
>> that now, and answer the questions along the way. I sent a separate
>> email discussing Justin’s patch review feedback.
>> 
>> In the build system today there is no strong distinction between
>> ‘projects’ and ‘tools’. There are a few subtle differences, but I’m
>> not sure any of them really matter. The differences are:
>> 
>> (1) The projects directory is always configured, tools can be disabled
>> using LLVM_INCLUDE_TOOLS=Off (projects and tools can both be
>> individually disabled too)
>> (2) Projects are configured before tools, so tools can rely on targets
>> being created for projects (we don’t really use this, and anywhere we
>> are is probably a bug)
>> (3) Some projects have special handling. For example test-suite isn’t
>> actually treated as a project, it has special handling in
>> LLVM/CMakeLists.txt:727, and Compiler-RT is handled by clang if you
>> set LLVM_BUILD_EXTERNAL_COMPILER_RT=On.
>> 
>> With this in mind I was thinking about the general usability of our
>> build system. The distinction between a project and a tool is not very
>> clear. At a high level I see three different use cases that are
>> covered by our current projects & tools directories.
>> 
>> (1) Projects that are configured with LLVM
>> (2) Runtime projects that should be configured using the just-built
tools
>> (3) The LLVM test-suite, which is really just external tests that
>> should be configured and run with the just-built tools
>> 
>> My proposal is that we make the tools subdirectory the *only* place
>> for projects that fall into category 1. I don’t think there is any
>> technical reason to drop an in-tree project into projects over tools
>> today, and I think we migrating people who are doing that away from it
>> should be easy.
>> 
>> Second I want to add a “runtimes” directory to LLVM to cover case 2
>> (see D20992). The idea behind this is to use common code in LLVM to
>> support building runtimes. This will allow the full LLVM toolchain to
>> be visible during configuration. I will abstract this functionality
>> into an installed CMake module so that Clang can use it for
>> out-of-tree clang builds.
>> 
>> Lastly we need to give the test-suite a new home. I’m not super
>> concerned with where we do that. It could be under tests, it could
>> just be at the root of the LLVM directory. I don’t think it matters
>> too much because it is a one-off. Thoughts welcome.
> 
> This all seems pretty sensible. Should we also use the opportunity to
> split compiler-rt's builtins and profiling/sanitizer/etc runtimes,
since
> we'll be moving things around anyway?
About that… So this is a complicated issue, but we should discuss it. Building
compiler-rt as a monolithic chunk under the runtimes model is actually
problematic because it would have circular dependencies.

For example:

libclang_rt.asan.aarch64 depends on libcxx.aarch64, but libcxx.aarch64 depends
on libclang_rt.builtins.aarch64.

That means to satisfy the proper build dependencies you need to build clang,
then builtins, then libcxx, then the sanitizer libraries.

Since Compiler-RT’s build does support configuring the builtins directory
separately from the sanitizers, we could support this with my runtimes proposal
without changing anything else in Compiler-RT through the application of some
project-specific hacks. Not idea, but it means this doesn’t need to block my
proposal.

We should consider other alternatives, because it would nice to not have hacks.
As an added benefit, if we separated the builtins and sanitizers into separate
libraries we would be able to have the sanitizer libraries licensed the same way
as LLVM (with the attribution clause), which would limit the amount of code that
has its wonky modified license.

-Chris
> 
> Some place like test/external or test/integration would probably make
> sense. It could potentially also be used for other optional tests like
> debuginfo-tests, which are currently somewhat awkwardly checked out into
> clang's tests.
> 
>> My proposed patch makes the runtimes directory work for Compiler-RT,
>> but it doesn’t yet handle libcxxabi, libcxx and libunwind. There is
>> some special case handling between libcxxabi and libcxx that will need
>> to be handled to make the dependencies work between the two, and I
>> still need to work that out.
>> 
>> If we want to go with this proposal I envision the transition being
>> multi-staged:
>> 
>> (1) Adding the new functionality, getting it up and fully working for
>> all runtime projects - this will involve changes to runtime projects
>> (2) Work with bot maintainers to migrate bots, and fix any issues that
come up
>> (3) Add support for a new secondary location for the test-suite
>> (4) Set a date for removing the projects directory, post patches
>> including updated documentation
> 
> Sure, but we might as well update the documentation earlier (in step 1)
> - as soon as compiler-rt can live in runtimes it makes sense to tell
> people to put it there, even if we still have legacy logic to make it
> continue to work out of projects as well.
> 
>> (5) Remove the projects directory entirely
>> 
>> Thoughts?
>> -Chris
>> 
>>> On Jun 8, 2016, at 6:59 PM, Chandler Carruth <chandlerc at
gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>> 
>>> On Wed, Jun 8, 2016 at 4:39 PM Justin Bogner via llvm-commits
>>> <llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org> <mailto:llvm-commits at lists.llvm.org
<mailto:llvm-commits at lists.llvm.org>>>
>>> wrote:
>>> Chris Bieneman <beanz at apple.com <mailto:beanz at
apple.com> <mailto:beanz at apple.com <mailto:beanz at
apple.com>>> writes:
>>>> beanz created this revision.
>>>> beanz added reviewers: chandlerc, bogner.
>>>> beanz added a subscriber: llvm-commits.
>>>> 
>>>> There are a few LLVM projects that produce runtime libraries.
Ideally
>>>> runtime libraries should be built differently than other
projects,
>>>> specifically they should be built using the just-built
toolchain.
>>>> 
>>>> There is support for building compiler-rt in this way from the
clang
>>>> build. Moving this logic into the LLVM build is interesting
because it
>>>> provides a simpler way to extend the just-built toolchain to
include
>>>> LLD and the LLVM object file tools.
>>>> 
>>>> Once this functionality is better fleshed out and tested we’ll
want to
>>>> encapsulate it in a module that can be used for clang
standalone
>>>> builds, and we’ll want to make it the default way to build
compiler-rt.
>>>> 
>>>> With this patch applied there is no immediate change in the
build.
>>>> Moving compiler-rt out from llvm/projects into llvm/runtimes
enables
>>>> the functionality.
>>> 
>>> This seems reasonable, but I am a little worried about how
transitioning
>>> to the new system will work. Will everyone have to move their
>>> compiler-rt checkout? Will we continue to support compiler-rt in
either
>>> place? Both of these are workable, but neither is great. Thoughts?
>>> 
>>> I share your concerns, but I also kind of like the direction this
is going.
>>> 
>>> But there is a higher-level meta-point: do we want to keep the
>>> 'projects' directory *at all*.
>>> 
>>> Every single resident of it I can think of except for the
test-suite
>>> is either dead (dragonegg) or a runtime library.
>>> 
>>> I think we should either have all the build-integrated projects in
a
>>> single 'projects' directory (including LLD and Clang), or
we should
>>> have none of them and use more domain relevant organization (today
>>> "tools", you're adding "runtimes", maybe we
move the test-suite to
>>> go under one of the test directories).
>>> 
>>> I think we should have a consistent plan here before moving
>>> stuff. But once we have it, I think we shouldn't be afraid of
>>> re-organizing stuff to make more sense, and just work to get folks
>>> to update their checkouts.
>>> 
>>> -Chandler
>>> 
>>> 
>>>> This code has a few improvements over the method provided by
>>>> LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja
command is
>>>> always invoked, so changes to compiler-rt source files will get
built
>>>> properly, so this patch can be used for iterative development
with
>>>> just-built tools.
>>>> 
>>>> http://reviews.llvm.org/D20992
<http://reviews.llvm.org/D20992> <http://reviews.llvm.org/D20992
<http://reviews.llvm.org/D20992>>
>>>> 
>>>> Files:
>>>>  CMakeLists.txt
>>>>  cmake/modules/LLVMExternalProjectUtils.cmake
>>>>  runtimes/CMakeLists.txt
>>>> 
>>>> Index: runtimes/CMakeLists.txt
>>>>
==================================================================>>>>
--- /dev/null
>>>> +++ runtimes/CMakeLists.txt
>>>> @@ -0,0 +1,16 @@
>>>> +include(LLVMExternalProjectUtils)
>>>> +
>>>> +# Discover the projects that use CMake in the subdirectories.
>>>> +# Note that explicit cmake invocation is required every time a
new project is
>>>> +# added or removed.
>>>> +
>>>> +add_custom_target(runtimes)
>>>> +
>>>> +file(GLOB entries *)
>>>> +foreach(entry ${entries})
>>>> +  if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
>>>> +    get_filename_component(projName ${entry} NAME)
>>>> +    llvm_ExternalProject_Add(${projName} ${entry}
USE_TOOLCHAIN)
>>>> +    add_dependencies(runtimes ${projName})
>>>> +  endif()
>>>> +endforeach(entry)
>>>> Index: cmake/modules/LLVMExternalProjectUtils.cmake
>>>>
==================================================================>>>>
--- cmake/modules/LLVMExternalProjectUtils.cmake
>>>> +++ cmake/modules/LLVMExternalProjectUtils.cmake
>>>> @@ -29,7 +29,8 @@
>>>> #     Extra targets in the subproject to generate targets for
>>>> #   )
>>>> function(llvm_ExternalProject_Add name source_dir)
>>>> -  cmake_parse_arguments(ARG
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL"
>>>> +  cmake_parse_arguments(ARG
>>>> +   
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL;ALWAYS_CLEAN"
>>>>     "SOURCE_DIR"
>>>>    
"CMAKE_ARGS;TOOLCHAIN_TOOLS;RUNTIME_LIBRARIES;DEPENDS;EXTRA_TARGETS"
${ARGN})
>>>>   canonicalize_tool_name(${name} nameCanon)
>>>> @@ -52,6 +53,10 @@
>>>>     endif()
>>>>   endforeach()
>>>> 
>>>> +  if(ARG_ALWAYS_CLEAN)
>>>> +    set(always_clean clean)
>>>> +  endif()
>>>> +
>>>>   list(FIND TOOLCHAIN_TOOLS clang FOUND_CLANG)
>>>>   if(FOUND_CLANG GREATER -1)
>>>>     set(CLANG_IN_TOOLCHAIN On)
>>>> @@ -135,6 +140,14 @@
>>>>     CMAKE_ARGS ${${nameCanon}_CMAKE_ARGS}
>>>>                ${compiler_args}
>>>>                -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
>>>> +              
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
>>>> +              
-DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_OUTPUT_INTDIR}
>>>> +              
-DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
>>>> +               -DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
>>>> +               -DLLVM_ENABLE_WERROR=${LLVM_ENABLE_WERROR}
>>>> +               -DPACKAGE_VERSION=${PACKAGE_VERSION}
>>>> +               -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
>>>> +               -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
>>> 
>>> How did you decide which variables need to be passed through like
this?
>>> The set seems somewhat arbitrary, but I may be missing something
>>> obvious.
>>> 
>>>>                ${ARG_CMAKE_ARGS}
>>>>                ${PASSTHROUGH_VARIABLES}
>>>>     INSTALL_COMMAND ""
>>>> @@ -152,7 +165,7 @@
>>>>     ExternalProject_Add_Step(${name} force-rebuild
>>>>       COMMAND ${run_build}
>>>>       COMMENT "Forcing rebuild of ${name}"
>>>> -      DEPENDEES configure clean
>>>> +      DEPENDEES configure ${always_clean}
>>> 
>>> I'm not sure I understand what this does. If I had to guess
I'd say that
>>> when ALWAYS_CLEAN is passed the rebuild of the external project
always
>>> invokes clean first, but if it's not passed we'll just
invoke the
>>> external build and allow it to be incremental if appropriate. Is
that
>>> right?
>>> 
>>>>       DEPENDS ${ALWAYS_REBUILD} ${ARG_DEPENDS}
${TOOLCHAIN_BINS}
>>>>       ${cmake_3_4_USES_TERMINAL} )
>>>>   endif()
>>>> Index: CMakeLists.txt
>>>>
==================================================================>>>>
--- CMakeLists.txt
>>>> +++ CMakeLists.txt
>>>> @@ -720,6 +720,8 @@
>>>>   add_subdirectory(tools)
>>>> endif()
>>>> 
>>>> +add_subdirectory(runtimes)
>>>> +
>>>> if( LLVM_INCLUDE_EXAMPLES )
>>>>   add_subdirectory(examples)
>>>> endif()
>>>> @@ -730,7 +732,8 @@
>>>>     llvm_ExternalProject_Add(test-suite
${LLVM_MAIN_SRC_DIR}/projects/test-suite
>>>>       USE_TOOLCHAIN
>>>>       EXCLUDE_FROM_ALL
>>>> -      NO_INSTALL)
>>>> +      NO_INSTALL
>>>> +      ALWAYS_CLEAN)
>>>>   endif()
>>>>   add_subdirectory(test)
>>>>   add_subdirectory(unittests)
>>>> 
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org> <mailto:llvm-commits at lists.llvm.org
<mailto:llvm-commits at lists.llvm.org>>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160609/6e947e72/attachment-0001.html>

I'm great with moving the runtimes into their own directory and making 
cmake modules to standardize an interface between the LLVM build process 
and the runtime build process.  I would like to ask for more though.

I find working with the runtimes a bit frustrating at times, and I think 
a lot of that frustration stems from the second-class nature of the 
runtime build process.  The "best" way to build just the runtimes
today
is to clone them in the llvm tree, pass a very long cmake line, then run 
a very specific make / ninja line (i.e. ninja cxx, ninja 
check-libcxxabi).  This is even the case if I don't want to use the 
freshly generated compiler.  Here are some specific nuisances that 
running in-tree has caused me:

  * I routinely need to pull a new LLVM for new cmake files, even though
    I am not building LLVM.
  * I don't get to use "standard" commands to build and test the
    components I work with.  I want to just run make / ninja with no
    arguments, but instead, I need to build specific targets.
  * Choices made for LLVM's build end up affecting mine, and I don't
    have a good way to change them.  For example, I wanted to perform
    some libcxx builds without -Wl,-z,defs.  I had to do some wacky
    string filtering to remove it from the compile line after the fact,
    instead of preventing it from getting added in the first place. 
    There wasn't a flag available on the LLVM side to disable it at
    configure time.
  * To get cmake to work, I have to set HAVE_CXX_ATOMICS_WITHOUT_LIB,
    even though I have no intention of building LLVM.  I then get to set
    LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB too, because reasons.
  * Multi-libs require multiple independent build directories, with all
    the associated cmake overhead.

So why not run out of tree instead you may ask?

  * No lit tests or lit utilities (FileCheck, not, etc...)
  * Even more difficult to manage dependencies between libcxxabi and libcxx

So some things I would like to see...

  * Standalone runtime builds should use the "normal" build interfaces
    (bare make, make all, make check, make install. s/make/ninja as
    desired).
  * For in-tree builds, LLVM would use the new cmake ExternalProject
    feature.  This way LLVM's in-tree support could be implemented in
    terms of the runtime's "normal" build interfaces.  LLVM may
also
    define a refinement of that interface to provide extra LLVM
    information on top.
      o For example, maybe all llvm runtime projects get passed
        something like LLVM_RUNTIME_LIBCXXABI_PRESENT and
        LLVM_RUNTIME_LIBCXXABI_PATH, and those projects can act on that
        or not.
  * Developers using standalone builds can use the same "LLVM build"
    interface as the in-tree builds use.
  * Break out testing infrastructure to a common repo, so that the
    runtimes can have access to the testing "banana" without dragging
    along the LLVM "gorilla".



On 6/9/2016 12:20 PM, Chris Bieneman via llvm-dev wrote:
> Moving to llvm-dev (I think this has gone a bit further than a patch 
> review discussion)
>
> In hindsight I probably should have explained more of my thinking on 
> this with the patch, or done an RFC on llvm-dev to start with. I’l do 
> that now, and answer the questions along the way. I sent a separate 
> email discussing Justin’s patch review feedback.
>
> In the build system today there is no strong distinction between 
> ‘projects’ and ‘tools’. There are a few subtle differences, but I’m 
> not sure any of them really matter. The differences are:
>
> (1) The projects directory is always configured, tools can be disabled 
> using LLVM_INCLUDE_TOOLS=Off (projects and tools can both be 
> individually disabled too)
> (2) Projects are configured before tools, so tools can rely on targets 
> being created for projects (we don’t really use this, and anywhere we 
> are is probably a bug)
> (3) Some projects have special handling. For example test-suite isn’t 
> actually treated as a project, it has special handling in 
> LLVM/CMakeLists.txt:727, and Compiler-RT is handled by clang if you 
> set LLVM_BUILD_EXTERNAL_COMPILER_RT=On.
>
> With this in mind I was thinking about the general usability of our 
> build system. The distinction between a project and a tool is not very 
> clear. At a high level I see three different use cases that are 
> covered by our current projects & tools directories.
>
> (1) Projects that are configured with LLVM
> (2) Runtime projects that should be configured using the just-built tools
> (3) The LLVM test-suite, which is really just external tests that 
> should be configured and run with the just-built tools
>
> My proposal is that we make the tools subdirectory the *only* place 
> for projects that fall into category 1. I don’t think there is any 
> technical reason to drop an in-tree project into projects over tools 
> today, and I think we migrating people who are doing that away from it 
> should be easy.
>
> Second I want to add a “runtimes” directory to LLVM to cover case 2 
> (see D20992). The idea behind this is to use common code in LLVM to 
> support building runtimes. This will allow the full LLVM toolchain to 
> be visible during configuration. I will abstract this functionality 
> into an installed CMake module so that Clang can use it for 
> out-of-tree clang builds.
>
> Lastly we need to give the test-suite a new home. I’m not super 
> concerned with where we do that. It could be under tests, it could 
> just be at the root of the LLVM directory. I don’t think it matters 
> too much because it is a one-off. Thoughts welcome.
>
> My proposed patch makes the runtimes directory work for Compiler-RT, 
> but it doesn’t yet handle libcxxabi, libcxx and libunwind. There is 
> some special case handling between libcxxabi and libcxx that will need 
> to be handled to make the dependencies work between the two, and I 
> still need to work that out.
>
> If we want to go with this proposal I envision the transition being 
> multi-staged:
>
> (1) Adding the new functionality, getting it up and fully working for 
> all runtime projects - this will involve changes to runtime projects
> (2) Work with bot maintainers to migrate bots, and fix any issues that 
> come up
> (3) Add support for a new secondary location for the test-suite
> (4) Set a date for removing the projects directory, post patches 
> including updated documentation
> (5) Remove the projects directory entirely
>
> Thoughts?
> -Chris
>
>> On Jun 8, 2016, at 6:59 PM, Chandler Carruth <chandlerc at gmail.com
>> <mailto:chandlerc at gmail.com>> wrote:
>>
>> On Wed, Jun 8, 2016 at 4:39 PM Justin Bogner via llvm-commits 
>> <llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org>> wrote:
>>
>>     Chris Bieneman <beanz at apple.com <mailto:beanz at
apple.com>> writes:
>>     > beanz created this revision.
>>     > beanz added reviewers: chandlerc, bogner.
>>     > beanz added a subscriber: llvm-commits.
>>     >
>>     > There are a few LLVM projects that produce runtime libraries.
>>     Ideally
>>     > runtime libraries should be built differently than other
projects,
>>     > specifically they should be built using the just-built
toolchain.
>>     >
>>     > There is support for building compiler-rt in this way from the
>>     clang
>>     > build. Moving this logic into the LLVM build is interesting
>>     because it
>>     > provides a simpler way to extend the just-built toolchain to
>>     include
>>     > LLD and the LLVM object file tools.
>>     >
>>     > Once this functionality is better fleshed out and tested we’ll
>>     want to
>>     > encapsulate it in a module that can be used for clang
standalone
>>     > builds, and we’ll want to make it the default way to build
>>     compiler-rt.
>>     >
>>     > With this patch applied there is no immediate change in the
build.
>>     > Moving compiler-rt out from llvm/projects into llvm/runtimes
>>     enables
>>     > the functionality.
>>
>>     This seems reasonable, but I am a little worried about how
>>     transitioning
>>     to the new system will work. Will everyone have to move their
>>     compiler-rt checkout? Will we continue to support compiler-rt in
>>     either
>>     place? Both of these are workable, but neither is great. Thoughts?
>>
>>
>> I share your concerns, but I also kind of like the direction this is 
>> going.
>>
>> But there is a higher-level meta-point: do we want to keep the 
>> 'projects' directory *at all*.
>>
>> Every single resident of it I can think of except for the test-suite 
>> is either dead (dragonegg) or a runtime library.
>>
>> I think we should either have all the build-integrated projects in a 
>> single 'projects' directory (including LLD and Clang), or we
should
>> have none of them and use more domain relevant organization (today 
>> "tools", you're adding "runtimes", maybe we
move the test-suite to go
>> under one of the test directories).
>>
>> I think we should have a consistent plan here before moving stuff. 
>> But once we have it, I think we shouldn't be afraid of
re-organizing
>> stuff to make more sense, and just work to get folks to update their 
>> checkouts.
>>
>> -Chandler
>>
>>
>>     > This code has a few improvements over the method provided by
>>     > LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja
>>     command is
>>     > always invoked, so changes to compiler-rt source files will
get
>>     built
>>     > properly, so this patch can be used for iterative development
with
>>     > just-built tools.
>>     >
>>     >http://reviews.llvm.org/D20992
>>     >
>>     > Files:
>>     >   CMakeLists.txt
>>     >   cmake/modules/LLVMExternalProjectUtils.cmake
>>     >   runtimes/CMakeLists.txt
>>     >
>>     > Index: runtimes/CMakeLists.txt
>>     >
==================================================================>>    
> --- /dev/null
>>     > +++ runtimes/CMakeLists.txt
>>     > @@ -0,0 +1,16 @@
>>     > +include(LLVMExternalProjectUtils)
>>     > +
>>     > +# Discover the projects that use CMake in the subdirectories.
>>     > +# Note that explicit cmake invocation is required every time
a
>>     new project is
>>     > +# added or removed.
>>     > +
>>     > +add_custom_target(runtimes)
>>     > +
>>     > +file(GLOB entries *)
>>     > +foreach(entry ${entries})
>>     > +  if(IS_DIRECTORY ${entry} AND EXISTS
${entry}/CMakeLists.txt)
>>     > +    get_filename_component(projName ${entry} NAME)
>>     > +    llvm_ExternalProject_Add(${projName} ${entry}
USE_TOOLCHAIN)
>>     > +    add_dependencies(runtimes ${projName})
>>     > +  endif()
>>     > +endforeach(entry)
>>     > Index: cmake/modules/LLVMExternalProjectUtils.cmake
>>     >
==================================================================>>    
> --- cmake/modules/LLVMExternalProjectUtils.cmake
>>     > +++ cmake/modules/LLVMExternalProjectUtils.cmake
>>     > @@ -29,7 +29,8 @@
>>     >  #     Extra targets in the subproject to generate targets for
>>     >  #   )
>>     >  function(llvm_ExternalProject_Add name source_dir)
>>     > -  cmake_parse_arguments(ARG
>>     "USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL"
>>     > +  cmake_parse_arguments(ARG
>>     > +
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL;ALWAYS_CLEAN"
>>     >      "SOURCE_DIR"
>>     >
>>    
"CMAKE_ARGS;TOOLCHAIN_TOOLS;RUNTIME_LIBRARIES;DEPENDS;EXTRA_TARGETS"
>>     ${ARGN})
>>     >    canonicalize_tool_name(${name} nameCanon)
>>     > @@ -52,6 +53,10 @@
>>     >      endif()
>>     >    endforeach()
>>     >
>>     > +  if(ARG_ALWAYS_CLEAN)
>>     > +    set(always_clean clean)
>>     > +  endif()
>>     > +
>>     >    list(FIND TOOLCHAIN_TOOLS clang FOUND_CLANG)
>>     >    if(FOUND_CLANG GREATER -1)
>>     >      set(CLANG_IN_TOOLCHAIN On)
>>     > @@ -135,6 +140,14 @@
>>     >      CMAKE_ARGS ${${nameCanon}_CMAKE_ARGS}
>>     >                 ${compiler_args}
>>     >  -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
>>     > + 
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
>>     > +  -DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_OUTPUT_INTDIR}
>>     > +  -DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
>>     > +  -DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
>>     > +  -DLLVM_ENABLE_WERROR=${LLVM_ENABLE_WERROR}
>>     > +  -DPACKAGE_VERSION=${PACKAGE_VERSION}
>>     > +  -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
>>     > +  -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
>>
>>     How did you decide which variables need to be passed through like
>>     this?
>>     The set seems somewhat arbitrary, but I may be missing something
>>     obvious.
>>
>>     >                 ${ARG_CMAKE_ARGS}
>>     >                 ${PASSTHROUGH_VARIABLES}
>>     >      INSTALL_COMMAND ""
>>     > @@ -152,7 +165,7 @@
>>     >      ExternalProject_Add_Step(${name} force-rebuild
>>     >        COMMAND ${run_build}
>>     >        COMMENT "Forcing rebuild of ${name}"
>>     > -      DEPENDEES configure clean
>>     > +      DEPENDEES configure ${always_clean}
>>
>>     I'm not sure I understand what this does. If I had to guess
I'd
>>     say that
>>     when ALWAYS_CLEAN is passed the rebuild of the external project
>>     always
>>     invokes clean first, but if it's not passed we'll just
invoke the
>>     external build and allow it to be incremental if appropriate. Is
that
>>     right?
>>
>>     >        DEPENDS ${ALWAYS_REBUILD} ${ARG_DEPENDS}
${TOOLCHAIN_BINS}
>>     >        ${cmake_3_4_USES_TERMINAL} )
>>     >    endif()
>>     > Index: CMakeLists.txt
>>     >
==================================================================>>    
> --- CMakeLists.txt
>>     > +++ CMakeLists.txt
>>     > @@ -720,6 +720,8 @@
>>     >    add_subdirectory(tools)
>>     >  endif()
>>     >
>>     > +add_subdirectory(runtimes)
>>     > +
>>     >  if( LLVM_INCLUDE_EXAMPLES )
>>     >    add_subdirectory(examples)
>>     >  endif()
>>     > @@ -730,7 +732,8 @@
>>     >      llvm_ExternalProject_Add(test-suite
>>     ${LLVM_MAIN_SRC_DIR}/projects/test-suite
>>     >        USE_TOOLCHAIN
>>     >        EXCLUDE_FROM_ALL
>>     > -      NO_INSTALL)
>>     > +      NO_INSTALL
>>     > +      ALWAYS_CLEAN)
>>     >    endif()
>>     >    add_subdirectory(test)
>>     >    add_subdirectory(unittests)
>>     >
>>
>>     _______________________________________________
>>     llvm-commits mailing list
>>     llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160609/8a41cdbe/attachment.html>

Hey Ben,

Thank you for providing this feedback. I’m going to lay out some ideas that I
have inline below.
> On Jun 9, 2016, at 11:26 AM, Craig, Ben via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I'm great with moving the runtimes into their own directory and making
cmake modules to standardize an interface between the LLVM build process and the
runtime build process.  I would like to ask for more though.
> 
> I find working with the runtimes a bit frustrating at times, and I think a
lot of that frustration stems from the second-class nature of the runtime build
process.  The "best" way to build just the runtimes today is to clone
them in the llvm tree, pass a very long cmake line, then run a very specific
make / ninja line (i.e. ninja cxx, ninja check-libcxxabi).  This is even the
case if I don't want to use the freshly generated compiler.  Here are some
specific nuisances that running in-tree has caused me:
> 
> 
Agree on all points. It might be useful to provide an alternate top-level CMake
file for runtime projects. There is some complication because the runtimes do
use CMake modules from LLVM, so you’ll need either an LLVM checkout or a built
& installed LLVM. My general hope in formalizing a runtimes directory is to
start treating runtimes as first-class members of the LLVM project. Admittedly
I’m coming from a different perspective than you, so I’m tackling the "LLVM
& Clang developer who also wants runtimes” side of the problem. I am,
however, sympathetic to your side too.
> I routinely need to pull a new LLVM for new cmake files, even though I am
not building LLVM.
Some of this may be avoidable through restructuring our CMake modules. I think
we should discuss this separately from the changes I’m asking for, but my
general idea is it might be reasonable to create a separate LLVM repository that
stores common CMake modules. If we did that it would require that *everyone*
building LLVM would need to have those modules. We may be able to hide that
complexity using CMake’s ExternalProject stuff. I’ll take it as a line item to
look into that.
> I don't get to use "standard" commands to build and test the
components I work with.  I want to just run make / ninja with no arguments, but
instead, I need to build specific targets.
This is the kind of thing I see as potentially solvable with a separate
top-level CMake file for runtimes. That said, in general I’ve been moving toward
adding more and more explicit targets into CMake. As a result of that my natural
workflow is involving less and less running general commands and more and more
running specific “ninja <some tool>” and “ninja check-llvm-<some test
set>”.
> Choices made for LLVM's build end up affecting mine, and I don't
have a good way to change them.  For example, I wanted to perform some libcxx
builds without -Wl,-z,defs.  I had to do some wacky string filtering to remove
it from the compile line after the fact, instead of preventing it from getting
added in the first place.  There wasn't a flag available on the LLVM side to
disable it at configure time.
LLVM’s flags impacting libcxx is fixed by my runtimes proposal. In fact, that’s
part of the point. Bleeding options from LLVM & Clang builds into runtime
libraries is not cool. It causes lots of problems on Darwin, so we’re sensitive
to this.
> To get cmake to work, I have to set HAVE_CXX_ATOMICS_WITHOUT_LIB, even
though I have no intention of building LLVM.  I then get to set
LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB too, because reasons.
This is bad. I’m curious why you need to set those ever. Have you diagnosed
this? For you to need to set that it means the host toolchain isn’t properly
passing the CMake checks.
> Multi-libs require multiple independent build directories, with all the
associated cmake overhead.
I strongly believe that for building multi-lib or more generally when building
for multiple targets you want multiple build directories, and in particular the
multiple-cmake invocations. I believe this because you want the checks to be
relevant for the target, and the only way to do that is to run the checks once
per target.

That said, I also strongly believe that for any user of our projects we should
find a way to have a single simple CMake invocation that gets the end result
that you want. I don’t believe these are mutually exclusive goals.

One of the development steps of the new runtime directory will be supporting
specifying multiple targets to build the runtimes for, and having CMake
construct the appropriate number of build directories and manage building them
all through a single top-level configuration and build directory. If you’re
skeptical about how doable this is I’d encourage you to look at this bot ->
http://lab.llvm.org:8011/builders/clang-3stage-ubuntu.

That bot does a full 3-stage clang build from a single CMake invocation:

cmake -C ../llvm.src/tools/clang/cmake/caches/3-stage.cmake -GNinja
-DLLVM_TARGETS_TO_BUILD=all -DLLVM_BINUTILS_INCDIR=/opt/binutils/include
../llvm.src
> So why not run out of tree instead you may ask?
> 
> No lit tests or lit utilities (FileCheck, not, etc…)
I don’t know if the runtimes you’re building are setup for this or not, but you
can get out-of-tree tests working if you have an LLVM installation on the system
or a build directory that you can point at. Compiler-RT does this. It isn’t
ideal but it is workable.

We should have a better solution.
> Even more difficult to manage dependencies between libcxxabi and libcxx
Yep. That sucks.
> So some things I would like to see...
> 
> Standalone runtime builds should use the "normal" build
interfaces (bare make, make all, make check, make install.  s/make/ninja as
desired).
I think this is doable, but I’m hesitant to rope it in with what I’m trying to
do here. Nothing I want to do would prevent this or make it any harder than it
already is.
> For in-tree builds, LLVM would use the new cmake ExternalProject feature. 
This way LLVM's in-tree support could be implemented in terms of the
runtime's "normal" build interfaces.  LLVM may also define a
refinement of that interface to provide extra LLVM information on top.
> For example, maybe all llvm runtime projects get passed something like
LLVM_RUNTIME_LIBCXXABI_PRESENT and LLVM_RUNTIME_LIBCXXABI_PATH, and those
projects can act on that or not.
Yes, there will need to be a mechanism for communicating project dependencies
between runtimes.
> Developers using standalone builds can use the same "LLVM build"
interface as the in-tree builds use.
Yes. I’ve actually been having some hallway conversations about how to
standardize the build interface a bit more cleanly. Some of this will depend on
a per-project basis, but I think compiler-rt does some of this right today.

Specifically if an LLVM build tree is available it builds as if it were in-tree
and being distributed with that build. If the LLVM build tree isn’t available,
it builds in a more standard *nix format that would be compatible with non-LLVM
toolchains. I may be wrong, but I think that is probably the right behavior for
all our runtimes.
> Break out testing infrastructure to a common repo, so that the runtimes can
have access to the testing "banana" without dragging along the LLVM
"gorilla”.
I’m hesitant to suggest more and more repos because I think there are some
challenges and additional burdens with that. I do understand the benefit of what
you’re asking for here, and I think it is worth considering. I think there is an
argument for splitting out the LLVM testing infrastructure, as well as an
argument for splitting out the LLVM build infrastructure.

In both cases I think those changes are larger than what I’m proposing, but
worth considering.

-Chris

Obligatory troll: Maybe we should move to github and change the whole repo
structure in the process?
> 
> On 6/9/2016 12:20 PM, Chris Bieneman via llvm-dev wrote:
>> Moving to llvm-dev (I think this has gone a bit further than a patch
review discussion)
>> 
>> In hindsight I probably should have explained more of my thinking on
this with the patch, or done an RFC on llvm-dev to start with. I’l do that now,
and answer the questions along the way. I sent a separate email discussing
Justin’s patch review feedback.
>> 
>> In the build system today there is no strong distinction between
‘projects’ and ‘tools’. There are a few subtle differences, but I’m not sure any
of them really matter. The differences are:
>> 
>> (1) The projects directory is always configured, tools can be disabled
using LLVM_INCLUDE_TOOLS=Off (projects and tools can both be individually
disabled too)
>> (2) Projects are configured before tools, so tools can rely on targets
being created for projects (we don’t really use this, and anywhere we are is
probably a bug)
>> (3) Some projects have special handling. For example test-suite isn’t
actually treated as a project, it has special handling in
LLVM/CMakeLists.txt:727, and Compiler-RT is handled by clang if you set
LLVM_BUILD_EXTERNAL_COMPILER_RT=On.
>> 
>> With this in mind I was thinking about the general usability of our
build system. The distinction between a project         and a tool is not very
clear. At a high level I see three different use cases that are covered by our
current projects & tools directories.
>> 
>> (1) Projects that are configured with LLVM
>> (2) Runtime projects that should be configured using the just-built
tools
>> (3) The LLVM test-suite, which is really just external tests that
should be configured and run with the just-built tools
>> 
>> My proposal is that we make the tools subdirectory the *only* place for
projects that fall into category 1. I don’t think there is any technical reason
to drop an in-tree project into projects over tools today, and I think we
migrating people who are doing that away from it should be easy.
>> 
>> Second I want to add a “runtimes” directory to LLVM to cover case 2
(see D20992). The idea behind this is to use common code in LLVM to support
building runtimes. This will allow the full LLVM toolchain to be visible during
configuration. I will abstract this functionality into an installed CMake module
so that Clang can use it for out-of-tree clang builds.
>> 
>> Lastly we need to give the test-suite a new home. I’m not super
concerned with where we do that. It could be under tests, it could just be at
the root of the LLVM directory. I don’t think it matters too much because it is
a one-off. Thoughts welcome.
>> 
>> My proposed patch makes the runtimes directory work for Compiler-RT,
but it doesn’t yet handle libcxxabi, libcxx and libunwind. There is some special
case handling between libcxxabi and libcxx that will need to be handled to make
the dependencies work between the two, and I still need to work that out.
>> 
>> If we want to go with this proposal I envision the transition being
multi-staged:
>> 
>> (1) Adding the new functionality, getting it up and fully working for
all runtime projects - this will involve changes to runtime projects
>> (2) Work with bot maintainers to migrate bots, and fix any issues that
come up
>> (3) Add support for a new secondary location for the test-suite
>> (4) Set a date for removing the projects directory, post patches
including updated documentation
>> (5) Remove the projects directory entirely
>> 
>> Thoughts?
>> -Chris
>> 
>>> On Jun 8, 2016, at 6:59 PM, Chandler Carruth <chandlerc at
gmail.com <mailto:chandlerc at gmail.com>> wrote:
>>> 
>>> On Wed, Jun 8, 2016 at 4:39 PM Justin Bogner via llvm-commits <
<mailto:llvm-commits at lists.llvm.org>llvm-commits at lists.llvm.org
<mailto:llvm-commits at lists.llvm.org>> wrote:
>>> Chris Bieneman <beanz at apple.com <mailto:beanz at
apple.com>> writes:
>>> > beanz created this revision.
>>> > beanz added reviewers: chandlerc, bogner.
>>> > beanz added a subscriber: llvm-commits.
>>> >
>>> > There are a few LLVM projects that produce runtime libraries.
Ideally
>>> > runtime libraries should be built differently than other
projects,
>>> > specifically they should be built using the just-built
toolchain.
>>> >
>>> > There is support for building compiler-rt in this way from the
clang
>>> > build. Moving this logic into the LLVM build is interesting
because it
>>> > provides a simpler way to extend the just-built toolchain to
include
>>> > LLD and the LLVM object file tools.
>>> >
>>> > Once this functionality is better fleshed out and tested we’ll
want to
>>> > encapsulate it in a module that can be used for clang
standalone
>>> > builds, and we’ll want to make it the default way to build
compiler-rt.
>>> >
>>> > With this patch applied there is no immediate change in the
build.
>>> > Moving compiler-rt out from llvm/projects into llvm/runtimes
enables
>>> > the functionality.
>>> 
>>> This seems reasonable, but I am a little worried about how
transitioning
>>> to the new system will work. Will everyone have to move their
>>> compiler-rt checkout? Will we continue to support compiler-rt in
either
>>> place? Both of these are workable, but neither is great. Thoughts?
>>> 
>>> I share your concerns, but I also kind of like the direction this
is going.
>>> 
>>> But there is a higher-level meta-point: do we want to keep the
'projects' directory *at all*.
>>> 
>>> Every single resident of it I can think of except for the
test-suite is either dead (dragonegg) or a runtime library.
>>> 
>>> I think we should either have all the build-integrated projects in
a single 'projects' directory (including LLD and Clang), or we should
have none of them and use more domain relevant organization (today
"tools", you're adding "runtimes", maybe we move the
test-suite to go under one of the test directories).
>>> 
>>> I think we should have a consistent plan here before moving stuff.
But once we have it, I think we shouldn't be afraid of re-organizing stuff
to make more sense, and just work to get folks to update their checkouts.
>>> 
>>> -Chandler
>>>  
>>> 
>>> > This code has a few improvements over the method provided by
>>> > LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja
command is
>>> > always invoked, so changes to compiler-rt source files will
get built
>>> > properly, so this patch can be used for iterative development
with
>>> > just-built tools.
>>> >
>>> > 
<http://reviews.llvm.org/D20992>http://reviews.llvm.org/D20992
<http://reviews.llvm.org/D20992>
>>> >
>>> > Files:
>>> >   CMakeLists.txt
>>> >   cmake/modules/LLVMExternalProjectUtils.cmake
>>> >   runtimes/CMakeLists.txt
>>> >
>>> > Index: runtimes/CMakeLists.txt
>>> >
==================================================================>>>
> --- /dev/null
>>> > +++ runtimes/CMakeLists.txt
>>> > @@ -0,0 +1,16 @@
>>> > +include(LLVMExternalProjectUtils)
>>> > +
>>> > +# Discover the projects that use CMake in the subdirectories.
>>> > +# Note that explicit cmake invocation is required every time
a new project is
>>> > +# added or removed.
>>> > +
>>> > +add_custom_target(runtimes)
>>> > +
>>> > +file(GLOB entries *)
>>> > +foreach(entry ${entries})
>>> > +  if(IS_DIRECTORY ${entry} AND EXISTS
${entry}/CMakeLists.txt)
>>> > +    get_filename_component(projName ${entry} NAME)
>>> > +    llvm_ExternalProject_Add(${projName} ${entry}
USE_TOOLCHAIN)
>>> > +    add_dependencies(runtimes ${projName})
>>> > +  endif()
>>> > +endforeach(entry)
>>> > Index: cmake/modules/LLVMExternalProjectUtils.cmake
>>> >
==================================================================>>>
> --- cmake/modules/LLVMExternalProjectUtils.cmake
>>> > +++ cmake/modules/LLVMExternalProjectUtils.cmake
>>> > @@ -29,7 +29,8 @@
>>> >  #     Extra targets in the subproject to generate targets for
>>> >  #   )
>>> >  function(llvm_ExternalProject_Add name source_dir)
>>> > -  cmake_parse_arguments(ARG
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL"
>>> > +  cmake_parse_arguments(ARG
>>> > +   
"USE_TOOLCHAIN;EXCLUDE_FROM_ALL;NO_INSTALL;ALWAYS_CLEAN"
>>> >      "SOURCE_DIR"
>>> >     
"CMAKE_ARGS;TOOLCHAIN_TOOLS;RUNTIME_LIBRARIES;DEPENDS;EXTRA_TARGETS"
${ARGN})
>>> >    canonicalize_tool_name(${name} nameCanon)
>>> > @@ -52,6 +53,10 @@
>>> >      endif()
>>> >    endforeach()
>>> >
>>> > +  if(ARG_ALWAYS_CLEAN)
>>> > +    set(always_clean clean)
>>> > +  endif()
>>> > +
>>> >    list(FIND TOOLCHAIN_TOOLS clang FOUND_CLANG)
>>> >    if(FOUND_CLANG GREATER -1)
>>> >      set(CLANG_IN_TOOLCHAIN On)
>>> > @@ -135,6 +140,14 @@
>>> >      CMAKE_ARGS ${${nameCanon}_CMAKE_ARGS}
>>> >                 ${compiler_args}
>>> >                 -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
>>> > +              
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
>>> > +              
-DLLVM_LIBRARY_OUTPUT_INTDIR=${LLVM_LIBRARY_OUTPUT_INTDIR}
>>> > +              
-DLLVM_RUNTIME_OUTPUT_INTDIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
>>> > +               -DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX}
>>> > +               -DLLVM_ENABLE_WERROR=${LLVM_ENABLE_WERROR}
>>> > +               -DPACKAGE_VERSION=${PACKAGE_VERSION}
>>> > +               -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
>>> > +               -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
>>> 
>>> How did you decide which variables need to be passed through like
this?
>>> The set seems somewhat arbitrary, but I may be missing something
>>> obvious.
>>> 
>>> >                 ${ARG_CMAKE_ARGS}
>>> >                 ${PASSTHROUGH_VARIABLES}
>>> >      INSTALL_COMMAND ""
>>> > @@ -152,7 +165,7 @@
>>> >      ExternalProject_Add_Step(${name} force-rebuild
>>> >        COMMAND ${run_build}
>>> >        COMMENT "Forcing rebuild of ${name}"
>>> > -      DEPENDEES configure clean
>>> > +      DEPENDEES configure ${always_clean}
>>> 
>>> I'm not sure I understand what this does. If I had to guess
I'd say that
>>> when ALWAYS_CLEAN is passed the rebuild of the external project
always
>>> invokes clean first, but if it's not passed we'll just
invoke the
>>> external build and allow it to be incremental if appropriate. Is
that
>>> right?
>>> 
>>> >        DEPENDS ${ALWAYS_REBUILD} ${ARG_DEPENDS}
${TOOLCHAIN_BINS}
>>> >        ${cmake_3_4_USES_TERMINAL} )
>>> >    endif()
>>> > Index: CMakeLists.txt
>>> >
==================================================================>>>
> --- CMakeLists.txt
>>> > +++ CMakeLists.txt
>>> > @@ -720,6 +720,8 @@
>>> >    add_subdirectory(tools)
>>> >  endif()
>>> >
>>> > +add_subdirectory(runtimes)
>>> > +
>>> >  if( LLVM_INCLUDE_EXAMPLES )
>>> >    add_subdirectory(examples)
>>> >  endif()
>>> > @@ -730,7 +732,8 @@
>>> >      llvm_ExternalProject_Add(test-suite
${LLVM_MAIN_SRC_DIR}/projects/test-suite
>>> >        USE_TOOLCHAIN
>>> >        EXCLUDE_FROM_ALL
>>> > -      NO_INSTALL)
>>> > +      NO_INSTALL
>>> > +      ALWAYS_CLEAN)
>>> >    endif()
>>> >    add_subdirectory(test)
>>> >    add_subdirectory(unittests)
>>> >
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org <mailto:llvm-commits at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>> 
>> 
>> _______________________________________________
>> 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>
> 
> -- 
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
> _______________________________________________
> 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/20160609/f3015dce/attachment.html>