From: Jack Howarth <howarth@br...> - 2013-02-13 14:28:50
I have posted refactored packaging for gromacs and gromacs-mpi to fink tracking...
The new gromacs release no longer supports configure and only builds with cmake now.
I have taken the opportunity to rationalize the packaging by refactoring gromacs
and gromacs-mpi. The *-bin and *-dev split-offs have been subsumed back into the
main package with only the *-shlibs being allowed to co-exist. I don't see a simple
and robust way to allow the main packages to co-exist as all they contain identical
files except for the executables with different basenames. IMHO, most users will
really want to settle on either the stock or parallel build. If there were a huge
demand for both, the most logical approach would be to have the gromac-mpi build
also build the stock build so that it would contain both sets of executables.
I added a patch to define and use VERSION in the appropriate CMakeLists.txt
files so that the 4.6 release produced the same *.6.0.0.dylib shared libraries
as the 4.5.6 release (which 4.6 is based on). There is a change in the compatibility
version from 7 down to 6 but this is valid. Cmake explicitly sets the compatibility
version to major.minor.patch whereas libtool just sets it to major+1. Since the
only documented requirement of the compatibility version is that it be equal to
or greater than the complete soversion, both are equally correct approaches.
The packaging has been 'fink -m' tested on x86_64 darwin10 and x86_64 darwin12.
I have made tree specific versions for the info files of both gromacs and
gromacs-mpi because the differences in the available mpi packages in both trees
makes the Depends/Conflicts/Replaces lines more confusing and too long when
you try to handle both trees. I think it is better to keep this packaging as
concise as possible for clarity. Thanks in advance for getting this committed.
ps We also could just eliminate the gromacs-mpi package entirely and subsume it
into gromacs. I noticed that Fedora effectively does that...
Howver, duplicating their split-off may be difficult since we would have to
transition off of our own. I was trying to avoid have unnecessary split-offs
which might trip up the upgrade process to new releases.