Add WiX installer support#1522
Conversation
Older CUDA versions may be used, so this will add the default CUDA install's nvvm binary path for easier deployment.
|
@shehzan10 can you look into this |
|
I am not well aware of the WiX system and will read up a bit about it. The disadvantage is that creating a secondary installer will be different from the installer we produce using NSIS. Hence it will have a different set of examples etc which will not be documented. We will also need to have the WiX option similar to RPM where is it only enabled by a build option. Otherwise Is this something we want done for 3.4.0? Based on that I'll change my priority to test the PR. |
| <Environment Id="ENVPATH" Action="set" | ||
| Name="PATH" Permanent="no" System="yes" Part="last" Value="[INSTALL_ROOT]lib"/> | ||
| <Environment Id="NVPATH" Action="set" | ||
| Name="PATH" Permanent="no" System="yes" Part="last" Value="[%CUDA_PATH]\nvvm\bin"/> |
There was a problem hiding this comment.
This (adding NVVM to path) is something we have discussed at length internally about and have consistently decided not to have in our installer. The single most important reason being that NVIDIA does not add it to Path themselves.
Other reasons include
- Making the PATH too long.
- Most people will not remove such a path manually if they do not know what added it.
There was a problem hiding this comment.
May be an alternative would be to have the installer copy nvvm.dll (if it exists) into arrayfire/lib ?
|
Yeah WiX needs an RTF license file unfortunately, I don't believe the markdown will work, but I could test it. I did try using the NSIS installer, but I found the one generated from cpack didn't create the AF_PATH variable which the official installers do. This WiX installer does do that, fortunately. I could amend this PR so that it doesn't add nvvm to the PATH, however, or at least have an option to add nvvm to the PATH. On my deployed systems, it's nice to have the nvvm automatically added to the PATH, and it's nice that the WiX uninstaller automatically removes it from the PATH as well. |
|
We do not use CPack to generate the Windows installer. We have a different set up for that. We generate Visual Studio files, sign the DLLs, add MKL/other dependencies etc which is better for the windows environment. I am certainly not opposed to the WiX installer. I think we can make it a lot better if we don't target 3.4.0. That will give us more time to test it out. |
|
That explains it then :) should I amend this PR to make those changes? |
|
Let me read/test it out a little and then we can talk in detail about what direction to take with this. |
|
|
||
| SET(CPACK_WIX_LICENSE_RTF "${PROJECT_SOURCE_DIR}/LICENSE.rtf") | ||
| SET(CPACK_WIX_PATCH_FILE "${PROJECT_SOURCE_DIR}/wix/WIXPatch.wxs") | ||
| SET(CPACK_WIX_UPGRADE_GUID "FF9E2D77-CDC7-4D24-8B7B-99D66EDEE862") |
There was a problem hiding this comment.
It's a unique identifier for the installer, used for when users upgrade to a newer version. The existing installation can be detected by this. This way multiple entries in Programs and Features aren't created, and the existing installation can be upgraded in place.
For more information, see: https://cmake.org/cmake/help/v3.6/module/CPackWIX.html
There was a problem hiding this comment.
@InBetweenNames I was wondering if this is randomly generated. If so does it need to change with every version ?
Can you also add some comments on when this string needs to be preserved and when it needs to be regenerated ?
There was a problem hiding this comment.
It is indeed randomly generated, and if you wanted to have multiple ArrayFire installations side by side, then this number could change. Otherwise, leaving this number intact allows for future versions of ArrayFire to replace existing versions on the system.
|
@InBetweenNames If you join our gitter we can have a more flowing conversation there. You can send me a private message over there. |
|
@InBetweenNames Once #2048 has been merged into master, can you please rebase your changes of master. |
|
@InBetweenNames We are handling NSIS64 and IFW generators via #2048 which will be used to produce our installer binaries going forward. We will add WIX support in the furture should it provide an definitive advantage over the current ones. However, you are always welcome to send your changes as well (please base your changes of our latest master once #2048 is merged). Thank you. |
|
Works for me! I'm no longer interested in pursuing this patchset, but
should I choose to revisit this I'll follow your advice.
…On Sat, Feb 24, 2018 at 9:34 PM, pradeep ***@***.***> wrote:
@InBetweenNames <https://github.com/inbetweennames> We are handling
NSIS64 and IFW generators via #2048
<#2048> which will be used to
produce our installer binaries going forward. We will add WIX support in
the furture should it provide an definitive advantage over the current
ones. However, you are always welcome to send your changes as well (please
base your changes of our latest master once #2048
<#2048> is merged). Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1522 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHdVjD-PpJ0I30zWKbNzLYs3g4NTwuIbks5tYMaggaJpZM4JXTnY>
.
|
On Windows, the WiX installer is nice since it lets you easily add and modify environment variables, enabling you to create convenient packages for deployment. This patch adds support for CMake's WiX generator in order to do that.