Re: [Rdkit-devel] [PATCH 2/2] Install libraries in ${RDKit_LibDir}

[Greg L. <gre...@gm...>]

Dear all,

On Fri, Jul 30, 2010 at 6:14 PM, Riccardo Vianello
<ric...@gm...> wrote:
>
> thanks for including that patch. I prepared an additional one, that
> would introduce some changes to the way the package version is
> managed. This way, installing the C++ shared libraries with more
> unix-friendly sonames linking to the real (versioned) library names, I
> think becomes easier.
>
> With this patch applied to the Packaging branch, the release
> identifiers are set by the top CMakeLists.txt,
>
> set(RDKit_Year "2010")
> set(RDKit_Quarter "3")
> set(RDKit_Revision "1pre")
> set(RDKit_ABI "1")
>
> and used inside RDKitUtils.cmake to set the output name and version
> properties of library targets. Moreover (to avoid having the release
> string defined in multiple places) the Code/RDGeneral/versions.h
> header is created at build-time starting from a corresponding
> Code/RDGeneral/versions.h.cmake template (attached, it's supposed to
> replace the current header file versions.h).
>
> ${RDKit_ABI} is new and used to build the libraries soname, the
> overall release name didn't change (rdkit.rdBase.rdkitVersion is still
> '2010Q3_1pre') and the naming of the unix shared library results in
> something like the following:
>
> libDepictor.so -> libDepictor.so.1
> libDepictor.so.1 -> libDepictor.so.1.20103.1pre
>
> I couldn't yet verify the behaviour of the windows counterpart to
> library versioning in RDKitUtils.cmake, that part will probabily
> strongly benefit a review (but I think it can be eventually just
> commented out), so this is more a proposal and a starting point than
> anything else, but I think a more formal versioning could be useful to
> the system-wide installation.

In principle these sound find to me, and I was able to apply them to
the packaging branch and get working code (which I've checked in).

I still need to test on Windows, which I will do tomorrow sometime,
and the mac, which I assume will just work.

A comment about the way this is going: it currently seems to be pretty
easy to get a system-wide installation (i.e. something in /opt or
/usr/local), which is great of packaging. But as a developer, I would
like to be able to have multiple copies of the code, so it would be
very nice to have current (trunk) "make install" behavior available:
i.e. copy the binaries back up into the current source tree. I will
look into this a bit over the next couple of days, but if anyone has
tips on how this can be accomplished I'd love to hear them.

-greg