Setting a custom install dir

[JulianThijssen]

Before with MV_INSTALL_DIR it used to be possible to set your own installation directory for plugins. Is it now still possible with Manivault_INSTALL_DIR?

As far as I can set it always gets set automatically to be in the install directory.

[JulianThijssen]

In general it now seems hard to build a plugin outside the dev bundle, because both Manivault_INSTALL_DIR and ManiVault_INCLUDE_DIR need to be set, and need to change based on configuration.

[alxvth]

You only need to set ManiVault_DIR to where the cmake is located, e.g. INSTALL_PATH/cmake/mv.

Manivault_INSTALL_DIR and ManiVault_INCLUDE_DIR are set automatically during the find_package call to match the location of where ManiVault was found.
Ideally, ManiVault_INCLUDE_DIR should not be necessary but as outlined in ManiVaultStudio/core#619 I don't know how to set that up with our current install directory structure.

I see that I didn't update the README of the ExamplePlugins with the ManiVault_DIR instructions...

Building a plugin outside the DevBundle should of course not be a hassle... when building the core standalone you have to define MV_INSTALL_DIR and then when building a plugin for that core ManiVault_DIR to basically INSTALL_PATH/cmake/mv. Setting the DIR like that is how most cmake find_packages are set up, with the _DIR directory containing the cmake setup file.

[alxvth]

Before with MV_INSTALL_DIR it used to be possible to set your own installation directory for plugins. Is it now still possible with Manivault_INSTALL_DIR?

Do you mean you want to build a plugin against one ManiVault core version and then install it somewhere else, like to a different ManiVault installation

[alxvth]

Currently you'd need to add some code snippet for that. E.g. define your MY_INSTALL_LOCATION after the find_package call do:

if(MY_INSTALL_LOCATION)
    set(Manivault_INSTALL_DIR "${MY_INSTALL_LOCATION}")
endif()

[JulianThijssen]

Before with MV_INSTALL_DIR it used to be possible to set your own installation directory for plugins. Is it now still possible with Manivault_INSTALL_DIR?

Do you mean you want to build a plugin against one ManiVault core version and then install it somewhere else, like to a different ManiVault installation

No I would like to set the installation folder of everything I build with the dev bundle to be a different one than the install folder that is automatically set.

[JulianThijssen]

You only need to set ManiVault_DIR to where the cmake is located, e.g. INSTALL_PATH/cmake/mv.

Manivault_INSTALL_DIR and ManiVault_INCLUDE_DIR are set automatically during the find_package call to match the location of where ManiVault was found. Ideally, ManiVault_INCLUDE_DIR should not be necessary but as outlined in ManiVaultStudio/core#619 I don't know how to set that up with our current install directory structure.

I see that I didn't update the README of the ExamplePlugins with the ManiVault_DIR instructions...

Building a plugin outside the DevBundle should of course not be a hassle... when building the core standalone you have to define MV_INSTALL_DIR and then when building a plugin for that core ManiVault_DIR to basically INSTALL_PATH/cmake/mv. Setting the DIR like that is how most cmake find_packages are set up, with the _DIR directory containing the cmake setup file.

Ok nice, that works for building plugins separate of the dev bundle :) I tend to ignore the _DIR variables, because many projects don't use them properly and indeed it doesn't seem to work for this version of Qt either.

[alxvth]

No I would like to set the installation folder of everything I build with the dev bundle to be a different one than the install folder that is automatically set.

I think that's also possible by adjusting the MV_INSTALL_DIR.

When building the core and plugins in one project by adding them all with add_subdirectory (like the DevBundle does), all plugins should follow the core, i.e. no need to set ManiVault_DIR for the plugins but just MV_INSTALL_DIR for the core.

The top level cmake file, that is automatically created by the DevBundle in the source folder, sets MV_INSTALL_DIR automatically but you should be able to overrride that entry in the CMake GUI or hardcode a different path in the cmake file.

[JulianThijssen]

As far as I could see, the MV_INSTALL_DIR in the top-level cmake is not used anymore. At least changing it to anything else did nothing for where stuff would be installed.

[alxvth]

Mhm, the core definitely uses MV_INSTALL_DIR and will err if it's not set.. I just tried changing it in a DevBundle and it would happily install everything somewhere else

https://github.com/ManiVaultStudio/core/blob/cd6be62d219427d9aedf233d1d31478c68762bcd/CMakeLists.txt#L11

[JulianThijssen]

Hm, okay indeed it works when changing it in CMake. I originally changed it in the file, which doesn't do anything, probably some caching. In fact, throughout everything I left that variable pointing to some path, and nothing ever installed there ever.

I also sort of suspected ManiVault_INSTALL_DIR to be the replacement of MV_INSTALL_DIR. So then, I think we should probably rename one of these variables, because having them both is a bit confusing. If MV_INSTALL_DIR is only meant to be used in the core, then that should probably be something like MV_CORE_INSTALL_DIR?

Perhaps even just using CMAKE_INSTALL_PREFIX is good enough then..

[alxvth]

Hm, okay indeed it works when changing it in CMake. I originally changed it in the file, which doesn't do anything, probably some caching. In fact, throughout everything I left that variable pointing to some path, and nothing ever installed there ever.

Ah ok, I think that might be a cmake thing that when using set(MY_VAR "a value" CACHE PATH "my description") it only uses "a value" if MY_VAR does not already exists in the cache.... so that once it was set, changing the default won't have any effect. A little annoying...

If MV_INSTALL_DIR is only meant to be used in the core, then that should probably be something like MV_CORE_INSTALL_DIR?

Yeah, we could do that. I recently started updating plugin settings to follow that pattern as well, i.e. MV_PCA_*, MV_SNE_*, MV_UMAP_* etc.

Edit: But if we do that, we have to remember to update every conanfile

Perhaps even just using CMAKE_INSTALL_PREFIX is good enough then..

That would work as well. I don't know for sure why CMAKE_INSTALL_PREFIX was never used, but I can imagine the first install implementation tried to do something fine-grained or explicit, not sure... I just kept that around to not change to much.