Paul,
Both or neither - for me it's important that RDKit::foo() is working in my
code, not which specific library it is in or
what other libraries the first lib depends upon. So if I need to use foo()
I'd like to know what to include into my Makefile.
That's why I suggested having a monolithic sta
I'd like to pick apart this comment:
On 19/08/2016 15:45, Igor Filippov wrote:
> It is sometimes a bit of a pain to collect the list of the dependencies.
Do you mean that (for example) if you wanted to link with
libMolChemicalFeatures, you also
have to add libSubstructureMatch and libSmilesPa
Compromise on "RDK"?
-P.
On Fri, Aug 19, 2016 at 10:50 AM, Paul Emsley
wrote:
> On 19/08/2016 12:52, Greg Landrum wrote:
> >
> > It seems logical to me, though I would probably go with RDKit instead of
> RD
> > as the prefix.
>
> OK, that's clearer yet.
>
>
>
> -
On 19/08/2016 12:52, Greg Landrum wrote:
>
> It seems logical to me, though I would probably go with RDKit instead of RD
> as the prefix.
OK, that's clearer yet.
--
___
Rdkit-
Ok, here's the issue in github:
https://github.com/rdkit/rdkit/issues/1036
These are famous last words, but it looks like adding this, and making it
optional, may be trivial. Cmake is *awesome*.
Let's move any technical discussion to github
-greg
On Fri, Aug 19, 2016 at 2:28 PM, Brian Kelley w
If we are talking about the changes to the way the libs are build is there
a chance to get a (possibly optional) monolithic static library?
It is sometimes a bit of a pain to collect the list of the dependencies.
Alternatively some easier way to discover what belongs to what library
would be apprec
On Fri, Aug 19, 2016 at 6:15 AM, Paul Emsley
wrote:
>
> It seems to me that several RDKit library names are too generic (and
> hence confusing) for such an environment: I have in mind libs such as
> Alignment, Catalog,
> FileParsers (and others). I suggest that all RDKit libraries are prefixed
>
Correct, it would be just changing the names of the C++ shared and static
libraries. No code changes would be required, just makefiles.
On Fri, Aug 19, 2016 at 4:22 PM, Rocco Moretti
wrote:
> On Fri, Aug 19, 2016 at 6:15 AM, Paul Emsley
> wrote:
>
>>
>> It seems to me that several RDKit library
On Fri, Aug 19, 2016 at 3:23 PM, Greg Landrum wrote:
>
> That sounds like an argument for doing it sooner rather than later...
>
Yeah, but really I don't think we are in a hurry here, so I'd consider
the timeline outlined by Brian pretty sensible.
--
Gianluca Sforna
http://plus.google.com/+gi
On Fri, Aug 19, 2016 at 2:54 PM, Gianluca Sforna wrote:
> On Fri, Aug 19, 2016 at 1:52 PM, Greg Landrum
> wrote:
>
> Of course, changing names is a bit of a hassle for those usign the
> previous names, as they needs to rebuild dependent packages; however,
> given there are none as of today, I do
On Fri, Aug 19, 2016 at 1:52 PM, Greg Landrum wrote:
> Nice suggestion. It seems logical to me, though I would probably go with
> RDKit instead of RD as the prefix.
> It's not a small change for people who are using the C++ libs without cmake
> (I wouldn't change the names of the cmake projects,
Perhaps announce at the RDKit meeting and make the full change for the
first release of next year? We could also make it a CMAKE option to
use/build the old names, but this would be a bit of work.
Cheers,
Brian
On Fri, Aug 19, 2016 at 7:52 AM, Greg Landrum
wrote:
> Hi Paul,
>
> Nice suggestio
Hi Paul,
Nice suggestion. It seems logical to me, though I would probably go with
RDKit instead of RD as the prefix.
It's not a small change for people who are using the C++ libs without cmake
(I wouldn't change the names of the cmake projects, so if you're using the
RDKit cmake stuff nothing chan
Greg,
RDKit is becoming increasingly popular and is getting picked up by third
parties, including
the Linux distros. It seems to me that several RDKit library names are too
generic (and
hence confusing) for such an environment: I have in mind libs such as
Alignment, Catalog,
FileParsers (a
14 matches
Mail list logo
