CMake error when compiling on linux

[flatstik]

cmake ..

...

CMake Error at CMakeLists.txt:214 (install):
  install TARGETS given no RUNTIME DESTINATION for executable target "mopac".

CMake Error at CMakeLists.txt:215 (install):
  install TARGETS given no RUNTIME DESTINATION for executable target
  "mopac-param".

CMake Error at CMakeLists.txt:216 (install):
  install TARGETS given no RUNTIME DESTINATION for executable target
  "mopac-makpol".

CMake Error at CMakeLists.txt:222 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "mopac-core".

Seems this has only been compiled on windows and no linux testing has been made?

CMakeLists.txt needs "DESTINATION "somepath" to generate the Makefile. I used /opt/openmopac for the "somepath".

install(TARGETS mopac RUNTIME COMPONENT main DESTINATION "somepath" )
install(TARGETS mopac-param RUNTIME COMPONENT extra DESTINATION "somepath" )
install(TARGETS mopac-makpol RUNTIME COMPONENT extra DESTINATION "somepath" )
if(WIN32)
  install(TARGETS mopac-core RUNTIME COMPONENT main)
#  install(TARGETS mopac-win RUNTIME COMPONENT extra)
  install(TARGETS mopac-bz RUNTIME COMPONENT extra)
else()
  install(TARGETS mopac-core LIBRARY COMPONENT main DESTINATION "somepath" )

After this cmake .. generates the Makefile which compiles without problem with just "make". With make install, it gives following:

-- Install configuration: ""
-- Installing: /opt/openmopac/mopac
-- Set runtime path of "/opt/openmopac/mopac" to "$ORIGIN/../lib"
-- Installing: /opt/openmopac/mopac-param
-- Set runtime path of "/opt/openmopac/mopac-param" to "$ORIGIN/../lib"
-- Installing: /opt/openmopac/mopac-makpol
-- Set runtime path of "/opt/openmopac/mopac-makpol" to "$ORIGIN/../lib"
-- Installing: /opt/openmopac/libmopac.so.1
-- Set runtime path of "/opt/openmopac/libmopac.so.1" to "$ORIGIN/../lib"
-- Installing: /opt/openmopac/libmopac.so

[susilehtola]

No it definitely has been tested on Linux. Please provide details on your system, which are altogether lacking at the moment.

[godotalgorithm]

Is this problem occurring with the 22.0.0 release version or the development version in the main branch?

We added include(GNUInstallDirs) to the CMake script in the development version last week, which was missing from the release. It populates the default installation directories for Linux machines, which are apparently left blank otherwise. This seems to be the problem you are encountering. The CMake install command shouldn't need a DESTINATION option set if the target type is specified (e.g. RUNTIME, LIBRARY) and the default install locations of those standard types is correctly populated.

We will be releasing a patch (22.0.1), hopefully later this week, resolving this and some other minor install-time and installer problems. However, if you are still seeing the same problem with the development version right now, please tell us and provide more information about your build environment such as the specific Linux distribution and version that you are using. I want to make sure that this issue will be resolved by the upcoming patch.

[flatstik]

The problem is occurring with the 22.0.0 release version and in the development version in the main branch, so the include(GNUInstallDirs) does not have any effect whatsoever

Build environment: Debian 10. 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux. All packages are installed with apt from the original repository and fully updated. I'm also more than happy to test future releases with this setup and report back problems if any.

cmake version 3.13.4

[flatstik]

Update: No problems with cmake version 3.18.4 (debian 11 bullseye)

[godotalgorithm]

This should be fixed by #41. Based on old CMake bug reports, there is a range of CMake versions that did not auto-populate default installation directories. I've added failsafe behavior that does this explicitly now but otherwise doesn't change any behavior when newer versions of CMake are used.

If your installation problem persists, please reopen this issue with more information. I'm closing the issue for now because I'm reasonably confident that this problem is resolved.