Development
1

I can’t imagine that we couldn’t just move this type of change into the
trunk. It’s just going to make us have to be a little smarter and will
cause our code to look a little less pretty. Dynamic cast would be
slow. What we need to do is just have it automatically cast.

Is it possible that we need to add our own ::createAtom functions that
return a pointer to an Avogadro::Atom?

–
Donald

----- Forwarded message from Marc Espie espie@nerim.net -----

2

On Feb 5, 2008, at 10:29 AM, Donald Ephraim Curtis wrote:

I can’t imagine that we couldn’t just move this type of change into
the
trunk. It’s just going to make us have to be a little smarter and
will
cause our code to look a little less pretty.

I’m more than happy to have this type of change in our development
trunk. This will obviously go back into KDE before KDE-4.1.

My one worry is that our current dev trunk depends on Open Babel 2.2,
which currently has reported problems with gcc-3.4. I don’t have
access to any machines with GCC < 4.0. Is there an OpenBSD compile farm?

I’m happy to make sure we support older compilers. But it’s tricky
since I don’t have those compilers to continually test. That tends to
lead to bitrot.

Any suggestions?

Thanks very much,
-Geoff

3

On Feb 6, 2008 8:41 PM, Geoffrey Hutchison geoff.hutchison@gmail.com wrote:

On Feb 5, 2008, at 10:29 AM, Donald Ephraim Curtis wrote:

I can’t imagine that we couldn’t just move this type of change into
the
trunk. It’s just going to make us have to be a little smarter and
will
cause our code to look a little less pretty.

I’m more than happy to have this type of change in our development
trunk. This will obviously go back into KDE before KDE-4.1.

My one worry is that our current dev trunk depends on Open Babel 2.2,
which currently has reported problems with gcc-3.4. I don’t have
access to any machines with GCC < 4.0. Is there an OpenBSD compile farm?

Can’t you install multiple versions of gcc on your platform?

I’m happy to make sure we support older compilers. But it’s tricky
since I don’t have those compilers to continually test. That tends to
lead to bitrot.

Any suggestions?

Thanks very much,
-Geoff

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

4

On Feb 6, 2008, at 6:43 PM, Tim Vandermeersch wrote:

On Feb 6, 2008 8:41 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

On Feb 5, 2008, at 10:29 AM, Donald Ephraim Curtis wrote:

I can’t imagine that we couldn’t just move this type of change into
the
trunk. It’s just going to make us have to be a little smarter and
will
cause our code to look a little less pretty.

I’m more than happy to have this type of change in our development
trunk. This will obviously go back into KDE before KDE-4.1.

My one worry is that our current dev trunk depends on Open Babel 2.2,
which currently has reported problems with gcc-3.4. I don’t have
access to any machines with GCC < 4.0. Is there an OpenBSD compile
farm?

Can’t you install multiple versions of gcc on your platform?

How many of our developers have access to and test using older
compilers? I know my Gentoo systems (if I ever get them back) now only
have GCC 4.1+ on them. I can’t remember if Gentoo currently supports
the older compilers anymore or not but they certainly aren’t
recommended. I think most other distros have a similar stance.

The C++ ABI broke once or twice in between 3.3 and 4.1 too so wouldn’t
that mean maintaining a chroot of Avogadro, OpenBabel and other linked
libs? Are the BSD platforms likely to want this backward compatibility
permanently or is work being done to get newer versions of GCC
working? I would certainly like to do what we can to make downstream’s
job easier but it would also be good to know what was expected of us
and whether it is feasible to maintain backwards compatibility longer
term.

Thanks,

Marcus