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

[Gianluca S. <gi...@gm...>]

On Mon, Aug 2, 2010 at 9:20 PM, Greg Landrum <gre...@gm...> wrote:
> 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.

I don't know if that's easily doable. However, rdkit is the only
project I worked on with a that kind of behaviour for "make install";
how exactly is that useful to you?



-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna