P , 2012-05-14 15:02 -0400, Geoffrey Hutchison rakstīja:
> > My guess is that all API breaking changes are still not allowed in trunk
> > (ABI breaks would be allowed for 2.4, but API breaks only for 3.0).
> 
> Right.
> 
> As for the "experimental" branch, it's essentially dead. I'd probably
> keep a new branch with a more descriptive name for any experiments.

I had that impression. Will play around in my own branch.

> 
> > I've started to clean up compiler warnings (cleaning up as fast as they
> > are committed ;) and would like to move on from there at some point. In
> > particular, I'm interested in the following topics:
> > - Compiler warnings, general cleanup
> 
> Yes, this is much appreciated. I apologize I miss-tracked your patch,
> but I'll be more responsive to these.

Glad to hear. There now is another set of fixes in patch tracker
(#3526485).

Also I have proposed patches for two bugs - #3526145 and #3526150.

And also there is an update for GRO format in patch tracker (#3526035).

>  You might also want to try
> compiling with Clang++, since it gives different sets of warnings from
> GCC/G++ by default.
> 
> http://clang.llvm.org/
> http://clang-analyzer.llvm.org/
> 

I might to try it at some point, but for now my targets are gcc4.6 and
also static build and then gcc4.7.

> > - Using size_t for counts and sizes etc.
> > - Indexing change (1 to 0 based)
> > - Boost's shared pointers or equivalent for automatic reference counting
> 
> Hmm. I think most of these should be pushed towards a 3.0 release. I'm
> not sure how you fix the atom indexing without breaking API. I guess at
> a minimum, we can start to internally use GetAtomById() or GetIndex()
> which use 0-based indexing.

The idea was for now to convert all internal functions to use 0-based
indexing, neither API nor ABI has to change for that afaik. That would
make the semantics of indexing consistent internally for OB.

> 
> Similarly, size_t and Boost will likely affect API as well as ABI. (If
> you have clever work-arounds which keep the API, I'm open to them.)

AFAIK size_t could be used internally in the place of unsigned int
without breaking neither API nor ABI, but using it in function
signatures would change API, so that part should go for 3.0. Correct me
if I'm wrong.

Boost introduces another dependency for OB so I guess it should go for
3.0.

> 
> > By the way, is a general migration to git still off the table?
> 
> I'm OK with this, but I think we'd need a more comprehensive vote.

That is two, how about others? :)


Reinis



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Reply via email to