[Lldb-commits] [PATCH] D61956: [CMake] Add first CMake cache files

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added inline comments.


================
Comment at: lldb/cmake/caches/Apple-lldb-macOS.cmake:10
+set(CMAKE_INSTALL_PREFIX "${CMAKE_CURRENT_BINARY_DIR}/install/Developer/usr")
+set(LLDB_FRAMEWORK_INSTALL_DIR "${CMAKE_CURRENT_BINARY_DIR}/install/SharedFrameworks" CACHE STRING "")
+
----------------
labath wrote:
> sgraenitz wrote:
> > Follow-up from: https://reviews.llvm.org/D61956?id=199645#inline-550727
> > 
> > > I believe the expected usage of this variable is to make it point to the final resting place of the executables, ...
> > 
> > It's been a pragmatic decision. Maybe we can improve this. The rationale was, that the default configuration should give the user something that works without touching caches or overriding parameters. In a previous sketch I used a real-world destination like:
> > ```
> > set(CMAKE_INSTALL_PREFIX /Applications/Xcode.app/Contents/Developer/usr/)
> > ```
> > But then `ninja install` would fail by default due to lack of permissions in the install destination. Actual release configurations tend to be more complex anyway and vendors will have their own downstream repos / caches for it. Thus, choosing a good default for developers sounded like a good way forward. What do you think?
> > 
> > > Are you sure including {CMAKE_CURRENT_BINARY_DIR} here is a good idea? I think llvm tries to avoid that generally, ...
> > 
> > What exactly do you mean? Having absolute paths, or paths into the build-tree, or the `CMAKE_CURRENT_BINARY_DIR` specifically? I don't see problems with the two last points. Am I missing something?
> > 
> > For the first: choosing an absolute path was for consistency with `LLDB_FRAMEWORK_INSTALL_DIR`. In the current build logic, they can both be absolute paths. Otherwise:
> > * if the install prefix is relative, it will be appended to the path of the root build directory
> > * if the framework install dir is relative, it will be appended to the install prefix
> > 
> > > Then, if you want to copy the to-be-installed files into a staging area first, you're expected to do that with "DESTDIR=whatever ninja install".
> > 
> > [Clang cache scripts](https://github.com/llvm/llvm-project/blob/a8f88c38/clang/cmake/caches/Apple-stage1.cmake#L4) seem to accomplish it manually, which may look like this (but the default would again fail due to privileges):
> > ```
> > if($ENV{DESTDIR})
> >   set(CMAKE_INSTALL_PREFIX $ENV{DESTDIR})
> >   set(LLDB_FRAMEWORK_INSTALL_DIR "../../SharedFrameworks" CACHE STRING "")
> > else()
> >   set(CMAKE_INSTALL_PREFIX /Applications/Xcode.app/Contents/Developer/usr)
> >   set(LLDB_FRAMEWORK_INSTALL_DIR /Applications/Xcode.app/Contents/SharedFrameworks CACHE STRING "")
> > endif()
> > ```
> > 
> > Would you (and other reviewers) prefer this solution?
> > But then ninja install would fail by default due to lack of permissions in the install destination. Actual release configurations tend to be more complex anyway and vendors will have their own downstream repos / caches for it. Thus, choosing a good default for developers sounded like a good way forward. What do you think?
> 
> I don't think most developers actually run the "install" rule TBH. :) But if they do, I think we should encourage them to do the right thing, and run "DESTDIR=foo ninja install", which will work even with a real-world prefix. At least that is the right thing to do in the linuxy world -- on a mac I guess most people will not be able to install lldb to the system destination anyway, so I'm not sure what would be a sensible default.
> 
> > Would you (and other reviewers) prefer this solution?
> 
> I don't care that much about this TBH. I just wanted to explain the difference between the install prefix and destdir, because in my experience, a lot of people get those two mixed up. ccing  @mgorny, in case I'm saying something wrong, as he does a lot of building and installing..
> I just wanted to explain the difference between the install prefix and destdir

Yes, that was a good point: DESTDIR is the location of the install-tree on the build machine, PREFIX is the install location on the enduser machine. Right? Sorry, I didn't come back to it. The Clang cache script I referred to, doesn't respect that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61956/new/

https://reviews.llvm.org/D61956