This is an archive of the discontinued LLVM Phabricator instance.

[CMake]Allow user specified CPack Options
ClosedPublic

Authored by Naville on Nov 23 2022, 6:37 PM.

Details

Summary

This should allow downstream vendors to install multiple LLVM distributions in parallel.

Should we also patch the default values to allow multiple upstream llvm distribution?

Diff Detail

Event Timeline

Naville created this revision.Nov 23 2022, 6:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 23 2022, 6:37 PM
Naville requested review of this revision.Nov 23 2022, 6:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 23 2022, 6:37 PM

This patch deserves a FAQ so here we are:

  • Won't this break MSVC?
  • MSVC uses the one in `VS\2019\Professional\VC\Tools\LLVM` unless you manually override the *.prop settings
Naville edited the summary of this revision. (Show Details)Nov 23 2022, 6:44 PM

I am fine with the user-overridable variables. I am not sure about switching the install root - It would be fine to have LLVM/15.0.0 and LLVM/16.0.0 for example. But not sure if there is any big issues with switching the directory at this time. For our internal distribution we don't use this installer so it doesn't matter that much for me.

Let's wait for input from @hans and @pbo-linaro

The idea is nice. Should we allow user to override all this, or simply change default to LLVM/$version instead?

I have no clue if this would break anything with MSVC, why would it be a problem?
It's already possible to extract installer content (using 7z for instance), and relocate it without problem, so I don't expect changing install path would break something.

hans added a comment.Nov 24 2022, 1:20 AM

Allowing developers to override the variables sgtm.

I'm not sure about changing the default dir. Is it a common use case to have multiple versions installed? Users who want to can already select a different dir when installing. Also I think the installer will bring up a "Do you want to uninstall the old version before installing the new one", even if the install dir is changed. Having a default install dir without the version also makes it a little easier for simple scripts to find it.

But overall I don't feel strongly about this. Changing the dir probably shouldn't break anything, but I also don't know if there are real benefits?

Yeah I think I am on the same page as Hans here - let's make it overrideable but let's not change the default dir - it can already be changed by the user.

Naville added a comment.EditedNov 24 2022, 2:17 AM

@pbo-linaro

Simply change default to LLVM/$version instead?

This stops downstream vendors (myself included) from distributing their own fork and install side-by-side with LLVM official releases, which kinda defeats the purpose

@hans

Is it a common use case to have multiple versions installed

Many downstream vendors do, like Swift install a separate LLVM toolchain on macOS with each release, same applies for Windows at least for our company, due to sometimes compiler regressions and whatnot

Also I think the installer will bring up a "Do you want to uninstall the old version before installing the new one"

Don't think this is the case as long as CPACK_PACKAGE_INSTALL_REGISTRY_KEY is changed as well

Having a default install dir without the version also makes it a little easier for simple scripts to find it.

For windows I think it's also stored in system registry

@thieta

let's make it overrideable but let's not change the default dir - it can already be changed by the user.

Very fair point, hence this diff currently doesnt change the defaults

Considering that use case, then it seems to be the best approach. lgtm

thieta accepted this revision.Dec 5 2022, 11:25 PM
This revision is now accepted and ready to land.Dec 5 2022, 11:25 PM
This revision was landed with ongoing or failed builds.Dec 6 2022, 1:58 AM
This revision was automatically updated to reflect the committed changes.