On Thu, Feb 6, 2014 at 7:57 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote:> > Le 6 févr. 2014 à 16:20, Brad King <brad.king at kitware.com> a écrit : > > > On 02/06/2014 08:12 AM, Alexey Samsonov wrote: > >> Please note that it makes a lot of sense to built compiler-rt (and > sanitizers) with just-built > >> Clang. In fact, even though we should support building it with another > compilers (gcc, MSVC), > >> using just-built-Clang should be a default scenario, like it is in > configure+make build. > > > > This is possible with CMake using the ExternalProject module: > > > > > http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:ExternalProject > > > > The add_llvm_external_project macro already in LLVM could be taught > > to call ExternalProject_Add instead of add_subdirectory. This could > > create a custom target with dependencies appropriately configured to > > build after Clang. The custom target would run CMake to configure the > > project like an outside build and then launch the build. > > > > IIUC there is a desire for Clang to be able to be built externally to > > LLVM rather than subsumed into its build process. The top-level > > CMakeLists.txt file of Clang already has code to do that, though it > > can be much cleaner after my patches to LLVM to provide LLVMConfig.cmake > > are integrated. Then it will even be possible to build Clang using > > CMake against a LLVM that was built and installed using configure+make. > > > > If one would like to drive compiler-rt as part of testing a Clang built > > outside of LLVM then the appropriate place for the ExternalProject_Add > > call would be inside the build of Clang. > > Look like what we need to build compiler-rt. Actually the makefile > responsible to launch the compiler-rt build is in clang/runtime/compiler-rt. > Using ExternalProject_Add, we can probably add the CMake part beside that > existing file, so everything will be at the same place. >OK, I feel like I need to learn more about ExternalProject_Add magic. I have a few quick questions for people with knowledge - currently: 1) "compiler-rt"'s CMake needs to know about targets in the Clang build tree ("clang") and in LLVM build tree ("FileCheck", llvm-* command-line tools, googletest etc.), and uses common macro from LLVM's CMake modules like "configute_lit_site_cfg", "parse_arguments". 2) top-level targets from compiler-rt's CMake files are visible at the root of LLVM's build tree, so that I can run "make check-asan" or even "make clang_rt.asan-x86_64" from the root of the build tree. Will we easily retain all these capabilities if we turn compiler-rt into an external project?> > > Either way, from a quick glance at the top-level CMakeLists.txt file > > in compiler-rt it appears to want to know a bunch of information about > > Clang rather than LLVM. In this case having Clang export enough info > > for applications to write find_package(Clang) would make sense. This > > is possible to do an can be implemented using techniques similar to > > that in my proposed LLVMConfig.cmake patch series. > > > > -Brad > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- Jean-Daniel > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140206/372750bc/attachment.html>
On 02/06/2014 01:02 PM, Alexey Samsonov wrote:> OK, I feel like I need to learn more about ExternalProject_Add magic.It is the CMake equivalent to a configure+make build target that runs configure+make for another project.> I have a few quick questions for people with knowledge - currently: > 1) "compiler-rt"'s CMake needs to know about targets in the Clang build tree ("clang") and > in LLVM build tree ("FileCheck", llvm-* command-line tools, googletest etc.), and uses common > macro from LLVM's CMake modules like "configute_lit_site_cfg", "parse_arguments".This will be possible once LLVM and Clang are taught to provide proper content in LLVMConfig.cmake and ClangConfig.cmake package configuration files. The patch series I proposed in the thread Greg linked at the start of this thread is the first step to do that.> 2) top-level targets from compiler-rt's CMake files are visible at the root of LLVM's build tree, > so that I can run "make check-asan" or even "make clang_rt.asan-x86_64" from the root of > the build tree.This would not work with ExternalProject_Add because the CMake running on LLVM or Clang would not see the targets in compiler-rt since the project will not even be processed until build (make) time. In return the compiler-rt would be able to build using the just-built Clang because it will now be available when CMake runs on compiler-rt. (IIUC this is currently the case for configure+make.) Also compiler-rt could now be built outside of a LLVM/Clang that was built unaware of compiler-rt. It is also possible to make project/compiler-rt build optionally with add_subdirectory instead of ExternalProject_Add, as it does now, with the cost of not using the just-built Clang. -Brad
On Fri, Feb 7, 2014 at 1:59 AM, Brad King <brad.king at kitware.com> wrote:> On 02/06/2014 01:02 PM, Alexey Samsonov wrote: > > OK, I feel like I need to learn more about ExternalProject_Add magic. > > It is the CMake equivalent to a configure+make build target that > runs configure+make for another project. > > > I have a few quick questions for people with knowledge - currently: > > 1) "compiler-rt"'s CMake needs to know about targets in the Clang build > tree ("clang") and > > in LLVM build tree ("FileCheck", llvm-* command-line tools, googletest > etc.), and uses common > > macro from LLVM's CMake modules like "configute_lit_site_cfg", > "parse_arguments". > > This will be possible once LLVM and Clang are taught to provide proper > content in LLVMConfig.cmake and ClangConfig.cmake package configuration > files. The patch series I proposed in the thread Greg linked at the > start of this thread is the first step to do that. > > > 2) top-level targets from compiler-rt's CMake files are visible at the > root of LLVM's build tree, > > so that I can run "make check-asan" or even "make clang_rt.asan-x86_64" > from the root of > > the build tree. > > This would not work with ExternalProject_Add because the CMake > running on LLVM or Clang would not see the targets in compiler-rt > since the project will not even be processed until build (make) time. > In return the compiler-rt would be able to build using the just-built > Clang because it will now be available when CMake runs on compiler-rt. > (IIUC this is currently the case for configure+make.) Also compiler-rt > could now be built outside of a LLVM/Clang that was built unaware of > compiler-rt. >I see the benefit in using just-built Clang, but it's a pity to lose the ability to add convenient top-level targets from compiler-rt project. It also means that we'd need to add "fake" top-level custom targets (that would configure + build + do something) in compiler-rt build tree if we want to, say, run compiler-rt test suite as a part of "make check-all" command. I'll take a look at your patches for ExternalProject that were recently submitted.> > It is also possible to make project/compiler-rt build optionally > with add_subdirectory instead of ExternalProject_Add, as it does now, > with the cost of not using the just-built Clang. > > -Brad > >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140210/e331aaef/attachment.html>
Hi Brad,
I have a few questions regarding ExternalProject_Add. For me it doesn't
really work as expected.
I add the following code to the tools/clang/runtime/CMakeLists.txt to
configure compiler-rt as external project:
ExternalProject_Add(compiler-rt
#DEPENDS clang clang++ llvm-config
PREFIX ${CMAKE_BINARY_DIR}/projects/compiler-rt
SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
CMAKE_ARGS -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang
-DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++
-DCMAKE_BUILD_TYPE=Release
-DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
-DCOMPILER_RT_OUTPUT_DIR=${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}
-DCOMPILER_RT_INSTALL_PATH=lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION}
# -DCOMPILER_RT_INCLUDE_TESTS=ON
INSTALL_COMMAND ""
)
add_dependencies(compiler-rt clang clang++ llvm-config)
1) Looks like "DEPENDS" option is just broken - docs here (
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
state that you can pass CMake targets there, but if I uncomment that line,
I get errors like:
CMake Error at /usr/local/share/cmake-2.8/Modules/ExternalProject.cmake:720
(message):
External project "clang" has no stamp_dir
Call Stack (most recent call first):
/usr/local/share/cmake-2.8/Modules/ExternalProject.cmake:932
(ExternalProject_Get_Property)
/usr/local/share/cmake-2.8/Modules/ExternalProject.cmake:1488
(_ep_get_step_stampfile)
/usr/local/share/cmake-2.8/Modules/ExternalProject.cmake:1702
(_ep_add_configure_command)
tools/clang/runtime/CMakeLists.txt:18 (ExternalProject_Add)
as if "clang" was supposed to be another external project. FTR, I use
cmake
2.8.10.2.
2) The dependencies don't act as expected: if I run "make
compiler-rt", it
builds Clang, uses it to configure
compiler-rt and builds compiler-rt. But if I then change the Clang sources,
and re-run "make compiler-rt",
Clang is re-built, but compiler-rt is *not* re-configured or re-built,
while I definitely want this.
3) The same doc (
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
states that
"One drawback, however, is ExternalProject’s lack of full dependency
analysis. Changes in header files of an external project may
not cause an incremental rebuild of the affected sources that depend on
those headers."
Looks like even if I modify *sources* under projects/compiler-rt, and
re-run "make compiler-rt" from the build
directory, it doesn't re-build the compiler-rt libraries. This makes
incremental development simply impossible.
What am I doing wrong?
On Fri, Feb 7, 2014 at 1:59 AM, Brad King <brad.king at kitware.com>
wrote:
> On 02/06/2014 01:02 PM, Alexey Samsonov wrote:
> > OK, I feel like I need to learn more about ExternalProject_Add magic.
>
> It is the CMake equivalent to a configure+make build target that
> runs configure+make for another project.
>
> > I have a few quick questions for people with knowledge - currently:
> > 1) "compiler-rt"'s CMake needs to know about targets in
the Clang build
> tree ("clang") and
> > in LLVM build tree ("FileCheck", llvm-* command-line tools,
googletest
> etc.), and uses common
> > macro from LLVM's CMake modules like
"configute_lit_site_cfg",
> "parse_arguments".
>
> This will be possible once LLVM and Clang are taught to provide proper
> content in LLVMConfig.cmake and ClangConfig.cmake package configuration
> files. The patch series I proposed in the thread Greg linked at the
> start of this thread is the first step to do that.
>
> > 2) top-level targets from compiler-rt's CMake files are visible at
the
> root of LLVM's build tree,
> > so that I can run "make check-asan" or even "make
clang_rt.asan-x86_64"
> from the root of
> > the build tree.
>
> This would not work with ExternalProject_Add because the CMake
> running on LLVM or Clang would not see the targets in compiler-rt
> since the project will not even be processed until build (make) time.
> In return the compiler-rt would be able to build using the just-built
> Clang because it will now be available when CMake runs on compiler-rt.
> (IIUC this is currently the case for configure+make.) Also compiler-rt
> could now be built outside of a LLVM/Clang that was built unaware of
> compiler-rt.
>
> It is also possible to make project/compiler-rt build optionally
> with add_subdirectory instead of ExternalProject_Add, as it does now,
> with the cost of not using the just-built Clang.
>
--
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140221/e77c08c8/attachment.html>