LLVM.LLVM package does not register PATH

[saschanaz]

Brief description of your issue

... thus the clang command is not exposed to system.

Steps to reproduce

winget install LLVM.LLVM

Expected behavior

It should register PATH.

Actual behavior

It does not.

Environment

Windows Package Manager v0.3.11102 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19043.962
Package: Microsoft.DesktopAppInstaller v1.11.11102.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
--------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget

[denelon]

I'm not familiar with LLVM. It looks like a collection of command-line tools. I'm not sure if the installer registers the path or not. It may require a terminal restart to get the path if the installer does set the path.

[saschanaz]

@denelon It provides an option to register the path, and the manifest seems not to be using that option.

[denelon]

microsoft/winget-cli#222 is a feature request to refresh the path after install. Would that address this situation?

[saschanaz]

I don't think so, the default option from the installer is not to register path, but when someone install a package via CLI the default expectation is to get a path (IMO at least), so I think the manifest should be somehow updated.

[denelon]

Is setting the path just passing a flag to the installer? If that is the case, the switches could be modified to pass the flag. If it requires passing the desired path to the installer, I'm not sure that would be an option at this point.

[saschanaz]

Is setting the path just passing a flag to the installer?

It gives three options in GUI:

• No PATH
• System PATH
• User PATH

I'm not sure what flag should be given (or whether it even receives a flag) when running it via CLI since I don't see a documentation for that.

[denelon]

The manifest has:

InstallerSwitches:
  InstallLocation: /D=<INSTALLPATH>

https://github.com/microsoft/winget-cli/tree/master/schemas/JSON/manifests/v1.0.0
lists the JSON schemas declaring what switches can be used.

It looks like this might be suitable for "Custom". You may need to test with a local manifest to see which one handles the scenario correctly. You can copy the manifest files to your local system and then winget install -m <path to manifest> to test locally. If you have the experimental "uninstall" feature enabled, you can quickly uninstall, modify the manifest, and try again. Remember you likely have to restart your terminal/shell to get the path variable to become active.

[saschanaz]

Only if I know what "custom" flag it receives 😄

[lychichem]

Maybe you should first try to know which tool is used to pack the installer. For example, when installed via winget, VSCode can register path/association/context menu by using switch --override '/silent /TASKS="addcontextmenufiles,addcontextmenufolders,associatewithfiles,addtopath"', and these switches are defined in the script used to package VSCode installer.
And @denelon , do you think we should add these switches to winget? For example, if a program want to add itself to path or register itself with some file association, it can use a switch like -addpath or -registerfileassociation? It will be really helpful for developer tools.

[saschanaz]

Seems it uses NSIS per the build script.

[lychichem]

Seems it uses NSIS per the build script.

This is not enough... See VSCode installer build script , you'll need to know the possible tasks/sections in install script.

[saschanaz]

CPACK_NSIS_MODIFY_PATH is the CPack API to add a relevant option page to the NSIS installer.

This is the underlying source to interact with NSIS, but I'm not sure what it really does.

[lychichem]

CPACK_NSIS_MODIFY_PATH is the CPack API to add a relevant option page to the NSIS installer.

This is the underlying source to interact with NSIS, but I'm not sure what it really does.

Maybe you can try the command listed here? By passing --override '<some commands>' to winget

[denelon]

Has anybody been able to determine which flags need to be passed to the installer to register the path for LLVM?

[saschanaz]

Chocolatey manually registers the path (see Install-ChocolateyPath at the last line), maybe the same should be done here?

[saschanaz]

I think I did respond 🤨

[saschanaz]

Can someone remove that label please?

[denelon]

Was this resolved by LLVM with their latest update?

[Trenly]

Was this resolved by LLVM with their latest update?

No; I was just looking at the wrong file. Sorry for the ghost ping

[nlhnt]

Still not resolved, ehh.
I had problems with scoop, because it registers some powershell script instead of the executable, so my IDE doesn't recognise the clang executable.
I thought, let's give winget a try, and it doesn't even register it, I don't even know where it was downloaded (wasn't reported by the tool during the installation).
I end up having to manually setup the path anyway, but first I need to manually figure out the installation.
Sorry that I sound dissapointed, I just expected a little bit more.
Keep up the good work I guess 👍🏻

[denelon]

@nlhnt,
We're working on:

• Support installing .zip files winget-cli#140

Some of the work in that feature is related to registering applications. Maybe there will be a way to leverage the path logic after that is complete. I'll bring it up to the team. Is LLVM open source? Maybe they would have insight into command line switches to register a path via silent install.

[superusercode]

Is LLVM open source? Maybe they would have insight into command line switches to register a path via silent install.

LLVM is open source. I started looking into the project since they use nullsoft for their installer but it's hard to tell how they have it configured since they use cmake on top (with the solution file equivalent here https://github.com/llvm/llvm-project/blob/main/llvm/CMakeLists.txt). I've put in an issue (llvm/llvm-project#54724) and will be able to determine from there if they have nullsoft configured to allow setting the path.

[superusercode]

LLVM uses cmake to generate their nullsoft installer, so they haven't enabled any commandline flags aside from the default nullsoft ones. In order to enable a silent install of LLVM that sets the path someone would have to contribute that option to the previously mentioned CMakeLists file.

This was explained in the most recent comment in response to the LLVM issue, and I will be adjusting the question into a feature request since I'm not sure how to implement this myself.

[denelon]

Related to:

• Add a commandline flag to enable adding LLVM to the system path during a silent install (on windows) llvm/llvm-project#54724

[jingkecn]

Try winget install -i LLVM.LLVM then you will have the option to register LLVM to the PATH for current user/all users.

[microsoft-github-policy-service]

Hello @saschanaz,

This issue has been identified as requiring a fix from a third party or external repository. Since there has been no recent activity on this issue, it will be automatically closed.

Template: msftbot/noRecentActivity/areaExternal