Shared build, but no shared library

[mbanck]

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like

Right now, one has to choose between a static build (-DSTATIC_BUILD=ON) which builds a static executable, and the default, which builds a shared library and links the mopac excutable to it.

I'm not sure the shared library interface is stable and should be exposed to a Linux distribution? I think a middle-ground would be to link mopac dynamically, but linking the shared library objects into it directly.

[susilehtola]

Mopac is a pretty stable package since it's been around for decades. The Fedora package of mopac employs shared libraries.

[mbanck]

Fair enough, but is it used by a lot of other packages? I think that is where a shared library is of value.
I've patched it out like this for now:

--- ./CMakeLists.txt.orig	2023-01-12 23:25:33.243439918 +0100
+++ ./CMakeLists.txt	2023-01-12 23:26:12.483781924 +0100
@@ -97,7 +97,7 @@
   target_link_options(mopac-core PUBLIC "-static")
   set(BLA_STATIC ON)
 else()
-  add_library(mopac-core SHARED)
+  add_library(mopac-core STATIC)
 endif()
 set_target_properties(mopac-core PROPERTIES OUTPUT_NAME "mopac")
 add_executable(mopac)

[godotalgorithm]

There are two basic reasons for using shared libraries by default with MOPAC.

First, there are two executables, MOPAC and PARAM, that use a large fraction of the central features of the MOPAC codebase. If I were to statically link a library to each executable, then it would increase the size of the distribution by quite a bit for no reason.

Second, we are trying to position MOPAC for easier interfacing with other software, and having it be accessible as a shared library is a step in that direction. I've made some room for a MOPAC API, but it doesn't really do anything yet. Also, I have experimented with binding MOPAC to Python, which also requires that it be built as a shared library.