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

Jonathan Roelofs via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 13 07:16:24 PDT 2017


jroelofs 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})
----------------
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.


Repository:
  rL LLVM

https://reviews.llvm.org/D32816





More information about the llvm-commits mailing list