Updating macOS port on Macports to v5.8.0, vtk gets installed into /usr/local/

I’m trying to bump the version of Paraview on Macports, but after updating the version, the build gets to 100%, but VTK tries to get installed into /usr/local.

I have the feeling that the option -DMACOS_APP_INSTALL_PREFIX is not used anymore. Is there something I need to tweak?

:info:destroot make[2]: Nothing to be done for `Wrapping/Python/CMakeFiles/paraview_python_copy.dir/build'.
:info:destroot [100%] Built target paraview_python_copy
:info:destroot /opt/local/bin/cmake -E cmake_progress_start /opt/local/var/macports/build/_Users_rubendibattista_git_macports-ports_science_paraview/paraview/work/build/CMakeFiles 0
:info:destroot /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/Makefile2 preinstall
:info:destroot make[1]: Nothing to be done for `preinstall'.
:info:destroot Install the project...
:info:destroot /opt/local/bin/cmake -P cmake_install.cmake
:info:destroot -- Install configuration: "Release"
:info:destroot CMake Error at cmake_install.cmake:48 (file):
:info:destroot   file cannot create directory: /usr/local/lib/cmake/paraview-5.8/vtk.  Maybe
:info:destroot   need administrative privileges.

Those are the configure options Macports forwards to cmake:

opt/local/bin/cmake -G "CodeBlocks - Unix Makefiles"

@ben.boeckel @cory.quammen

Does it need sudo privileges? Though…it seems that macports needs to update their CMake options. The share/cmake/Modules subdirectory is old and there’s nothing setting CMAKE_INSTALL_PREFIX=/opt/local, so the default of /usr/local still applies.

Ehi @ben.boeckel, thanks. But the fact that CMAKE_INSTALL_PREFIX is missing is due to the fact that, theoretically, this should be an App bundle, shouldn’t it? For that reason, it should use -DMACOSX_APP_INSTALL_PREFIX as prefix to install the App bundle. Am I wrong?

And morevoer macports already has rights to write into /opt/local.

The problem here is that now it tries to install vtk following CMAKE_INSTALL_PREFIX instead of following the path for the App bundle.

It makes an app bundle, but it isn’t relocatable as a bundle (the prefix as a whole is the relocatable bit right now). It’s basically a standard Unix-style install layout with bin/Applications/paraview.app using relative paths into that prefix. For a relocatable bundle, the superbuild is necessary.

Yes, no problem about that. It always has been like that. So, do I need to specify the -DCMAKE_INSTALL_PREFIX then? :slight_smile:

Yeah, that’s the first step in the solution. I recommend going through Documentation/dev/build.md document to see what variables you actually need to set with the 9.0 release (since a lot of things got moved around). Anything not mentioned there or in CMake docs is either undocumented (and probably has some other way of handling it) or is no longer relevant.

Ehi @ben.boeckel could you please refer me to the part of CMakeLists.txt of ParaView that handles the creation of the macOS App bundle?

ParaView itself does not handle that. You need the paraview-superbuild for that. At least if you want a relocatable bundle.

The skeleton bundle in ParaView itself is made by add_executable(MACOSX_BUNDLE) in ParaViewClient.cmake.

I don’t necessarily want a relocatable bundle.

Before 5.8.0 (and maybe 5.7.0), the normal CMakeLists.txt from paraview was able to generate a non-relocatable bundle (there was the build option -DMACOSX_APP_INSTALL_PREFIX to set where to put it).

Can I now stll make it?

There’s still a bundle (bin/Applications/paraview.app I think), but the install prefix is the point of relocatability, not the paraview.app directory.

Hi Ruben, did you manage to get it fixed at the end?

Ehi Tiago, unfortunately I did not have anymore bandwith to investigate that. I plan to do that, but at the moment I’m busy with my PhD thesis. :slight_smile: