[PATCH] D32816: [CMake] Support multi-target runtimes build

Petr Hosek via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 13 16:09:30 PDT 2017


phosek added inline comments.


================
Comment at: cmake/modules/LLVMExternalProjectUtils.cmake:185
   if(NOT ARG_NO_INSTALL)
-    install(CODE "execute_process\(COMMAND \${CMAKE_COMMAND} -DCMAKE_INSTALL_PREFIX=\${CMAKE_INSTALL_PREFIX} -P ${BINARY_DIR}/cmake_install.cmake \)"
+    install(CODE "execute_process\(COMMAND \${CMAKE_COMMAND} -P ${BINARY_DIR}/cmake_install.cmake \)"
       COMPONENT ${name})
----------------
jroelofs wrote:
> beanz wrote:
> > jroelofs wrote:
> > > beanz wrote:
> > > > phosek wrote:
> > > > > jroelofs wrote:
> > > > > > phosek wrote:
> > > > > > > I'm not sure on what's the best way to handle the install prefix. When building runtimes for multiple targets, only one of them can use the "default" install prefix, others have to use a different one otherwise they'll overwrite each other files.
> > > > > > I'd shove them all under: `lib/clang-runtimes/$triple/{lib,include}`, and specifically not use a "default" install prefix.
> > > > > Now they will be installed in `$CMAKE_INSTALL_PREFIX/$target`, but I'd be happy to change that to `lib/runtimes/$target`. One issue I've noticed is that sanitizer and xray headers end up in `lib/runtimes/$target/lib/clang/5.0.0/include`. I don't know if those headers are target specific, but if not it would be better to install them in `lib/clang/5.0.0/include` same as for compiler headers.
> > > > The sanitizer headers are not (to my knowledge) sanitizer specific, so we should be able to install them once to `/lib/clang/$version/include`.
> > > > 
> > > > For the general target library path I think we need a more complicated solution if we want the install rules to be useful.
> > > > 
> > > > Static archives from compiler-rt should install to `/lib/clang/$version/lib/$sys/`, and shared libraries (and static archives from other runtime projects) should install to `/lib/$target/`, except in the case where `$target` == host, in which case it should just be `/lib`.
> > > > 
> > > > I'm not entirely sure how complicated this would be to implement, but I expect it will require changes to compiler-rt's build system to differentiate install paths of static and shared libraries.
> > > @beanz what about shared libs from the builtins build? shouldn't those still end up in `/lib/clang/$version/lib/$sys/`, since they're tied to the specific version of the compiler, unlike the rest of the runtime bits?
> > Presently we don't support shared libs from the builtins build at all. If we did, you'd likely want them to behave like the shared libraries from other runtime projects because you'd want them to be part of the sysroot for the cross target. At least, that's how I would assume you'd want them to work.
> good point.
I looked into different runtimes, libunwind, libc++abi and libc++ all define `${runtime}_LIBRARY_PATH` which could be used to install libraries for different targets into `/lib/$target`. Most headers are not target-specific, the only exception being `__config` which for some targets is generated by concatenating generated `__config_site` with `__config`. There're ways around this. One would be to completely ignore such targets. The other would be to surround the generated `__config_site` content with `#if defined(...)/#endif` block. This is going to require some libc++ changes though. Separating static and shared libraries in compiler-rt should be relatively straightforward: all runtimes use `add_compiler_rt_runtime` CMake function which sets both `ARCHIVE` and `LIBRARY` destination in the install target to `COMPILER_RT_LIBRARY_INSTALL_DIR`, so we just need to introduce another variable, e.g. `COMPILER_RT_ARCHIVE_INSTALL_DIR`. We would also need to modify Clang `ToolChain`; `getCompilerRT` currently assumes that both static and shared libraries are in the same directory, so we would need to change that.

This solution would require more changes in different components than the current version, but most of them (except maybe the libc++ `__config_site`) are pretty straightforward. If you think this is a cleaner solution, I'd be happy to go ahead and implement those changes, but I'd like to finally make some progress on this change. Do you think it'd make sense to start a thread on llvm-dev to make sure everyone is on board?


Repository:
  rL LLVM

https://reviews.llvm.org/D32816





More information about the llvm-commits mailing list