This is an archive of the discontinued LLVM Phabricator instance.

[runtimes] Allow overriding where CMake installs RUNTIME type libraries (DLLs)
ClosedPublic

Authored by mstorsjo on Aug 11 2021, 4:50 AM.

Details

Reviewers
phosek
compnerd
ldionne
Group Reviewers
Restricted Project
Restricted Project
Restricted Project
Commits
rGc4e8a2136c00: [runtimes] Allow overriding where CMake installs RUNTIME type libraries (DLLs)
Summary

Currently this is hardcoded to the directory 'bin' under the
install prefix, but when doing per-target runtime builds, all
of these would end up in the same bin directory (where that bin
directory is for the native compiler itself, not for cross target
executables).

Default to bin/${LLVM_DEFAULT_TARGET_TRIPLE}, and let the user
override it.

For existing per-target runtime configurations on Windows, this
does change where the output binaries are placed (but before,
one couldn't use it for more than one target at a time anyway
as the build products would clobber each other).

Diff Detail

Event Timeline

mstorsjo created this revision.Aug 11 2021, 4:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 11 2021, 4:50 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a subscriber: mgorny. · View Herald Transcript
mstorsjo requested review of this revision.Aug 11 2021, 4:50 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 11 2021, 4:50 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript

Why not just use CMAKE_RUNTIME_OUTPUT_DIRECTORY to initialize the value?

Why not just use CMAKE_RUNTIME_OUTPUT_DIRECTORY to initialize the value?

You mean instead of the e.g. set(LIBUNWIND_INSTALL_RUNTIME_DIR bin ... and set(LIBUNWIND_INSTALL_RUNTIME_DIR bin/${LLVM_DEFAULT_TARGET_TRIPLE} ... statements - making them e.g. set(LIBUNWIND_INSTALL_RUNTIME_DIR ${CMAKE_RUNTIME_OUTPUT_DIRECTORY} ...? By default CMAKE_RUNTIME_OUTPUT_DIRECTORY is unset it seems; such a setup makes the DLLs not be installed at all unless the user sets CMAKE_RUNTIME_OUTPUT_DIRECTORY.

Our own cmake code initializes CMAKE_RUNTIME_OUTPUT_DIRECTORY right below - so in libunwind/libcxxabi/libcxx, CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_ARCHIVE_OUTPUT_DIRECTORY and CMAKE_LIBRARY_OUTPUT_DIRECTORY aren't anything you can set as an end-user to influence where things are installed (as they're overwritten unconditionally), but the end user should set e.g. LIBUNWIND_INSTALL_LIBRARY_DIR instead.

@ldionne - This one is a bit simpler as it's not about any specific less-supported way of building the library, but just adding similar configurability for this part of the installed RUNTIME files as already exists for files in the LIBRARY category.

I really would prefer to avoid adding bin/<TRIPLE> to the default installation path. This doesn't match the defaults for most platforms (e.g. exherbo uses /usr/<triple>/bin - which would be a default value of ${LLVM_DEFAULT_TARGET_TRIPLE}/bin. On Windows, it seems that bin, bin64, bin64a is the style that Microsoft uses. Having to have different defaults seems unfortunate. Defaulting to bin and letting the user override it seems reasonable to me.

Defaulting to bin and letting the user override it seems reasonable to me.

Fair enough, we can leave that default at bin, as long as it’s settable.

phosek added a comment.Sep 8 2021, 9:45 AM

If we still need this, then I'd prefer ${LLVM_DEFAULT_TARGET_TRIPLE}/bin following https://wiki.debian.org/Multiarch/LibraryPathOverview.

mstorsjo updated this revision to Diff 371373.Sep 8 2021, 9:46 AM

Keep the default target dir as 'bin' for per-target runtimes build too.

phosek accepted this revision.Sep 8 2021, 9:52 AM

LGTM

If we still need this, then I'd prefer ${LLVM_DEFAULT_TARGET_TRIPLE}/bin following https://wiki.debian.org/Multiarch/LibraryPathOverview.

Well, this path is only ever used for windows builds - but yeah, that pattern, <triple>/bin is what I use for mingw things in general too.

But isn’t that a bit inconsistent when the other per-target files are installed into lib/<triple> and include/<triple>?

compnerd accepted this revision.Sep 8 2021, 10:23 AM

As to the comment on the consistency - there are a number of different layouts that are inconsistent with each other :-(. This is messy, and therefore forcing the user to specify the paths seems like a good compromise.

phosek added a comment.EditedSep 8 2021, 10:57 AM

If we still need this, then I'd prefer ${LLVM_DEFAULT_TARGET_TRIPLE}/bin following https://wiki.debian.org/Multiarch/LibraryPathOverview.

Well, this path is only ever used for windows builds - but yeah, that pattern, <triple>/bin is what I use for mingw things in general too.

But isn’t that a bit inconsistent when the other per-target files are installed into lib/<triple> and include/<triple>?

AFAIK the reason why these are different is that if your binary foo uses dynamic linking, then the shared libraries for <triple>/bin/foo would be in <triple>/lib which is different from lib/<triple> which contains libraries used when targeting <triple>.

If we still need this, then I'd prefer ${LLVM_DEFAULT_TARGET_TRIPLE}/bin following https://wiki.debian.org/Multiarch/LibraryPathOverview.

Well, this path is only ever used for windows builds - but yeah, that pattern, <triple>/bin is what I use for mingw things in general too.

But isn’t that a bit inconsistent when the other per-target files are installed into lib/<triple> and include/<triple>?

AFAIK the reason why these are different is that if your binary foo uses dynamic linking, then the shared libraries for <triple>/bin/foo would be in <triple>/lib which is different from lib/<triple> which contains libraries used when targeting <triple>.

To give a more practical albeit contrived example, you could end up with this:

x86_64-linux-gnu/
  bin/
    clang
  lib/
    libz.so
aarch86_64-linux-gnu/
  bin/
    clang
  lib/
    libz.so
include/
  ...
  riscv64-linux-gnu/
    ...
lib/
  riscv64-linux-gnu/
    libc++.a
ldionne accepted this revision.Sep 8 2021, 12:24 PM
This revision is now accepted and ready to land.Sep 8 2021, 12:24 PM