Avogadro Superpackage and Open Babel ABI

ghutchis · May 18, 2010, 6:30pm

Hi Marcus,

I’m having real troubles with the Mac superpackage builds because of some CMake issues.

Right now, we find the system’s libopenbabel.* file, but then link and copy the built libopenbabel files for the superpackage. The problem is that I build and rebuild OB frequently – sometimes with debugging, etc.

What I think we want is to use the bits when the Open Babel libraries aren’t found, although there’s no if/else case for Windows.

Could you take a look and fix this up?

Thanks,
-Geoff

Here’s the appropriate part of FindOpenBabel2.cmake:

if(EMBED_OPENBABEL)
MESSAGE(STATUS “Using Open Babel from superpackage”)
# Building a super-package, rely on the embedded paths
set(OPENBABEL2_VERSION_MET TRUE)
set(OPENBABEL2_INCLUDE_DIR {CMAKE_SOURCE_DIR}/openbabel/include {CMAKE_BINARY_DIR}/openbabel/include)
# This is a kludge – need to ask Marcus how to handle it better
find_library(OPENBABEL2_LIBRARIES NAMES openbabel openbabel-2
PATHS
{_obLinkDir} {GNUWIN32_DIR}/lib
ENV{OPENBABEL2_LIBRARIES} ) if (NOT OPENBABEL2_LIBRARIES) # look in superpackage if (APPLE) set(OPENBABEL2_LIBRARIES {CMAKE_BINARY_DIR}/lib/libopenbabel.dylib)
endif(APPLE)
if (UNIX AND NOT APPLE)
set(OPENBABEL2_LIBRARIES ${CMAKE_BINARY_DIR}/lib/libopenbabel.so)
endif(UNIX AND NOT APPLE)
endif (NOT OPENBABEL2_LIBRARIES)
# We know the embedded OB will be trunk
set (OPENBABEL_IS_NEWER_THAN_2_2_99 TRUE)
else(EMBED_OPENBABEL)

Konstantin_Tokarev · May 18, 2010, 8:19pm

I guess - maybe it’s better to look in superpacke before find_library?

Also, I’d recommended you to upgrade avogadro-super to my new version - maybe I’ve introduced some incompatible changes while getting variable exchange between projects.

18.05.10, 22:30, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

Hi Marcus,

I’m having real troubles with the Mac superpackage builds because of some CMake issues.

Right now, we find the system’s libopenbabel.* file, but then link and copy the built libopenbabel files for the superpackage. The problem is that I build and rebuild OB frequently – sometimes with debugging, etc.

What I think we want is to use the bits when the Open Babel libraries aren’t found, although there’s no if/else case for Windows.

Could you take a look and fix this up?

Thanks,
-Geoff

Here’s the appropriate part of FindOpenBabel2.cmake:

if(EMBED_OPENBABEL)
MESSAGE(STATUS “Using Open Babel from superpackage”)
# Building a super-package, rely on the embedded paths
set(OPENBABEL2_VERSION_MET TRUE)
set(OPENBABEL2_INCLUDE_DIR {CMAKE_SOURCE_DIR}/openbabel/include {CMAKE_BINARY_DIR}/openbabel/include)
# This is a kludge – need to ask Marcus how to handle it better
find_library(OPENBABEL2_LIBRARIES NAMES openbabel openbabel-2
PATHS
{_obLinkDir} {GNUWIN32_DIR}/lib
ENV{OPENBABEL2_LIBRARIES} ) if (NOT OPENBABEL2_LIBRARIES) # look in superpackage if (APPLE) set(OPENBABEL2_LIBRARIES {CMAKE_BINARY_DIR}/lib/libopenbabel.dylib)
endif(APPLE)
if (UNIX AND NOT APPLE)
set(OPENBABEL2_LIBRARIES ${CMAKE_BINARY_DIR}/lib/libopenbabel.so)
endif(UNIX AND NOT APPLE)
endif (NOT OPENBABEL2_LIBRARIES)
# We know the embedded OB will be trunk
set (OPENBABEL_IS_NEWER_THAN_2_2_99 TRUE)
else(EMBED_OPENBABEL)

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

–
Regards,
Konstantin

mhanwell · May 20, 2010, 12:04am

Hi Geoff,

Sorry about the delay in replying - didn’t have chance to go through mailing
lists yesterday. I have been meaning to fix up several issues in here that I
was not happy with. I will take a quick look now, otherwise I will have more
time on Saturday to dig through this if necessary.

Is there a spot where you could put the build directory up, or the
CMakeCache.txt? I would like to get any remaining issues fixed up, I thought it
was using the CMake target in the superbuild, but that may not be the case on
the Mac.

Thanks,

Marcus

On Tuesday 18 May 2010 14:30:14 Geoffrey Hutchison wrote:

Hi Marcus,

I’m having real troubles with the Mac superpackage builds because of some
CMake issues.

Right now, we find the system’s libopenbabel.* file, but then link and
copy the built libopenbabel files for the superpackage. The problem is
that I build and rebuild OB frequently – sometimes with debugging, etc.

What I think we want is to use the bits when the Open Babel libraries
aren’t found, although there’s no if/else case for Windows.

Could you take a look and fix this up?

Thanks,
-Geoff

Here’s the appropriate part of FindOpenBabel2.cmake:
if(EMBED_OPENBABEL)
MESSAGE(STATUS "Using Open Babel from superpackage")
# Building a super-package, rely on the embedded paths
set(OPENBABEL2_VERSION_MET TRUE)
set(OPENBABEL2_INCLUDE_DIR ${CMAKE_SOURCE_DIR}/openbabel/include
${CMAKE_BINARY_DIR}/openbabel/include) # This is a kludge -- need to
ask Marcus how to handle it better find_library(OPENBABEL2_LIBRARIES
NAMES openbabel openbabel-2

  PATHS
  ${_obLinkDir}
  ${GNUWIN32_DIR}/lib
  $ENV{OPENBABEL2_LIBRARIES}

)
if (NOT OPENBABEL2_LIBRARIES)

   # look in superpackage
   if (APPLE)

      set(OPENBABEL2_LIBRARIES
      ${CMAKE_BINARY_DIR}/lib/libopenbabel.dylib)

   endif(APPLE)
   if (UNIX AND NOT APPLE)

      set(OPENBABEL2_LIBRARIES
      ${CMAKE_BINARY_DIR}/lib/libopenbabel.so)

   endif(UNIX AND NOT APPLE)

endif (NOT OPENBABEL2_LIBRARIES)
# We know the embedded OB will be trunk
set (OPENBABEL_IS_NEWER_THAN_2_2_99 TRUE)
else(EMBED_OPENBABEL)
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

mhanwell · May 20, 2010, 3:55am

On Tuesday 18 May 2010 14:30:14 Geoffrey Hutchison wrote:

Hi Marcus,

I’m having real troubles with the Mac superpackage builds because of some
CMake issues.

Right now, we find the system’s libopenbabel.* file, but then link and
copy the built libopenbabel files for the superpackage. The problem is
that I build and rebuild OB frequently – sometimes with debugging, etc.

What I think we want is to use the bits when the Open Babel libraries
aren’t found, although there’s no if/else case for Windows.

Could you take a look and fix this up?

Hi Geoff,

As I don’t have access to an appropriate build environment to double check, I
would appreciate you trying to set,

set(OPENBABEL2_LIBRARIES openbabel)

When I wrote this at the time, I did not realize the evaluation order. The
openbabel should then be evaluated as the CMake target named openbabel, this
then embeds the actual path etc.

Then all of the stuff in FindOpenBabel2 for embedded can be removed, in favor
of checking whether the variables were set already. In fact, if the call is
cached, then it will only be run if the variable is not set, and so most of
this module could likely be removed.

In the work I have been doing with external projects target names are used,
and CMake is moving towards using exported targets in find modules where
possible too, as they can encapsulate much more data.

I can try these builds on a Linux host, and even Windows. If you don’t mind me
using one of your systems I could try a few test builds on a Mac too, in order
to ensure the builds are straight. It would remove all platform conditionals
from the Find file too, which I think is a good thing.

Having OpenBabel and Avogadro export these targets would mean the target names
could also be used after finding the libraries. This is something I have become
very familiar with in the last few weeks.

Marcus

Konstantin_Tokarev · May 20, 2010, 5:58pm

# We know the embedded OB will be trunk
set (OPENBABEL_IS_NEWER_THAN_2_2_99 TRUE)

You don’t need to assume it - BABEL_VERSION from OB sources is visible in superpackage

–
Regards,
Konstantin

Louis_Ricard · May 20, 2010, 6:40pm

Just a thought.

Could it be that some of the problems arise from the lack of
pkg-config on the Mac? Since I installed it, I have less trouble
compiling. Though I have not tried super-package build.

Louis

Le 20 mai 2010 à 02:04, Marcus D. Hanwell a écrit :

Hi Geoff,

Sorry about the delay in replying - didn’t have chance to go through mailing
lists yesterday. I have been meaning to fix up several issues in here that I
was not happy with. I will take a quick look now, otherwise I will have more
time on Saturday to dig through this if necessary.

Is there a spot where you could put the build directory up, or the
CMakeCache.txt? I would like to get any remaining issues fixed up, I thought it
was using the CMake target in the superbuild, but that may not be the case on
the Mac.

Thanks,

Marcus

On Tuesday 18 May 2010 14:30:14 Geoffrey Hutchison wrote:
Hi Marcus,

I’m having real troubles with the Mac superpackage builds because of some
CMake issues.

Right now, we find the system’s libopenbabel.* file, but then link and
copy the built libopenbabel files for the superpackage. The problem is
that I build and rebuild OB frequently – sometimes with debugging, etc.

What I think we want is to use the bits when the Open Babel libraries
aren’t found, although there’s no if/else case for Windows.

Could you take a look and fix this up?

Thanks,
-Geoff

Here’s the appropriate part of FindOpenBabel2.cmake:
if(EMBED_OPENBABEL)

MESSAGE(STATUS “Using Open Babel from superpackage”)

Building a super-package, rely on the embedded paths

set(OPENBABEL2_VERSION_MET TRUE)
set(OPENBABEL2_INCLUDE_DIR {CMAKE_SOURCE_DIR}/openbabel/include {CMAKE_BINARY_DIR}/openbabel/include) # This is a kludge – need to
ask Marcus how to handle it better find_library(OPENBABEL2_LIBRARIES
NAMES openbabel openbabel-2
 PATHS
 ${_obLinkDir}
 ${GNUWIN32_DIR}/lib
 $ENV{OPENBABEL2_LIBRARIES}
)
if (NOT OPENBABEL2_LIBRARIES)
  # look in superpackage
  if (APPLE)

     set(OPENBABEL2_LIBRARIES
     ${CMAKE_BINARY_DIR}/lib/libopenbabel.dylib)

  endif(APPLE)
  if (UNIX AND NOT APPLE)

     set(OPENBABEL2_LIBRARIES
     ${CMAKE_BINARY_DIR}/lib/libopenbabel.so)

  endif(UNIX AND NOT APPLE)
endif (NOT OPENBABEL2_LIBRARIES)

We know the embedded OB will be trunk

set (OPENBABEL_IS_NEWER_THAN_2_2_99 TRUE)

else(EMBED_OPENBABEL)
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

mhanwell · May 21, 2010, 10:15am

That would cause problems finding OpenBabel (last I looked at least). The
superbuild does not require pkg-config, as it bypasses the search by building
OpenBabel itself.

After having worked on a very large CMake build system for quite some time
now, I am convinced the most reliable way of doing this is to use CMake config
files, but that would require newer OB versions with these config files. I will
get to work in adding them though, as they tend to make life simpler and the
find more reliable.

Marcus

On Thursday 20 May 2010 14:40:59 Louis Ricard wrote:

Just a thought.

Could it be that some of the problems arise from the lack of
pkg-config on the Mac? Since I installed it, I have less trouble
compiling. Though I have not tried super-package build.

Louis

Le 20 mai 2010 à 02:04, Marcus D. Hanwell a écrit :
Hi Geoff,

Sorry about the delay in replying - didn’t have chance to go through
mailing lists yesterday. I have been meaning to fix up several issues in
here that I was not happy with. I will take a quick look now, otherwise
I will have more time on Saturday to dig through this if necessary.

Is there a spot where you could put the build directory up, or the
CMakeCache.txt? I would like to get any remaining issues fixed up, I
thought it was using the CMake target in the superbuild, but that may
not be the case on the Mac.

Thanks,

Marcus

On Tuesday 18 May 2010 14:30:14 Geoffrey Hutchison wrote:
Hi Marcus,

I’m having real troubles with the Mac superpackage builds because of
some CMake issues.

Right now, we find the system’s libopenbabel.* file, but then link and
copy the built libopenbabel files for the superpackage. The problem is
that I build and rebuild OB frequently – sometimes with debugging, etc.

What I think we want is to use the bits when the Open Babel libraries
aren’t found, although there’s no if/else case for Windows.

Could you take a look and fix this up?

Thanks,
-Geoff

Here’s the appropriate part of FindOpenBabel2.cmake:
if(EMBED_OPENBABEL)

MESSAGE(STATUS “Using Open Babel from superpackage”)

Building a super-package, rely on the embedded paths

set(OPENBABEL2_VERSION_MET TRUE)
set(OPENBABEL2_INCLUDE_DIR {CMAKE_SOURCE_DIR}/openbabel/include {CMAKE_BINARY_DIR}/openbabel/include) # This is a kludge – need to
ask Marcus how to handle it better find_library(OPENBABEL2_LIBRARIES
NAMES openbabel openbabel-2
 PATHS
 ${_obLinkDir}
 ${GNUWIN32_DIR}/lib
 $ENV{OPENBABEL2_LIBRARIES}
)
if (NOT OPENBABEL2_LIBRARIES)
  # look in superpackage
  if (APPLE)
  
     set(OPENBABEL2_LIBRARIES
     ${CMAKE_BINARY_DIR}/lib/libopenbabel.dylib)
  
  endif(APPLE)
  if (UNIX AND NOT APPLE)
  
     set(OPENBABEL2_LIBRARIES
     ${CMAKE_BINARY_DIR}/lib/libopenbabel.so)
  
  endif(UNIX AND NOT APPLE)
endif (NOT OPENBABEL2_LIBRARIES)

We know the embedded OB will be trunk

set (OPENBABEL_IS_NEWER_THAN_2_2_99 TRUE)

else(EMBED_OPENBABEL)
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Konstantin_Tokarev · May 21, 2010, 10:51am

That would cause problems finding OpenBabel (last I looked at least).
The superbuild does not require pkg-config, as it bypasses the search
by building OpenBabel itself.

After having worked on a very large CMake build system for quite some
time now, I am convinced the most reliable way of doing this is to
use CMake config files, but that would require newer OB versions with
these config files. I will get to work in adding them though, as they
tend to make life simpler and the find more reliable.

Sorry, but I really don’t see any difficulties in this situations. I’ve
introduced some changes into avogadro, openbabel and avogadro-super
build systems, and ported to stable branches. It’s reliable and tested
many times on Linux.

If presence of external OB prevents building of superpackage, it
shouldn’t be searched at all, IMHO

–
Regards,
Konstantin

ghutchis · May 21, 2010, 2:39pm

On May 21, 2010, at 6:15 AM, Marcus D. Hanwell wrote:

now, I am convinced the most reliable way of doing this is to use CMake config
files, but that would require newer OB versions with these config files. I will
get to work in adding them though, as they tend to make life simpler and the

The biggest concern here is with the trunk development version of OB, so there’s no issue with “newer OB versions.”

Best regards,
-Geoff

Prof. Geoffrey Hutchison
Department of Chemistry
University of Pittsburgh
tel: (412) 648-0492
email: geoff.hutchison@gmail.com
web: http://hutchison.chem.pitt.edu/

mhanwell · May 22, 2010, 2:09pm

On Friday 21 May 2010 06:51:26 Konstantin Tokarev wrote:

That would cause problems finding OpenBabel (last I looked at least).
The superbuild does not require pkg-config, as it bypasses the search
by building OpenBabel itself.

After having worked on a very large CMake build system for quite some
time now, I am convinced the most reliable way of doing this is to
use CMake config files, but that would require newer OB versions with
these config files. I will get to work in adding them though, as they
tend to make life simpler and the find more reliable.

Sorry, but I really don’t see any difficulties in this situations. I’ve
introduced some changes into avogadro, openbabel and avogadro-super
build systems, and ported to stable branches. It’s reliable and tested
many times on Linux.

That changes you introduced are only for Linux, and to be honest that was
never a massive target of mine as it already has lots of good package
managers. That said, still very worth having. It is not very cross platform
though,

If presence of external OB prevents building of superpackage, it
shouldn’t be searched at all, IMHO

if(UNIX AND NOT APPLE)
set(OPENBABEL2_LIBRARIES {openbabel_BINARY_DIR}/lib/libopenbabel.so) elseif(APPLE) set(OPENBABEL2_LIBRARIES {openbabel_BINARY_DIR}/lib/libopenbabel.dylib)
else()
set(OPENBABEL2_LIBRARIES ${openbabel_BINARY_DIR}/src/openbabel-2.lib)
endif()

This can actually become,

if(UNIX)
set(OPENBABEL2_LIBRARIES openbabel)
else(UNIX)
set(OPENBABEL2_LIBRARIES openbabel-2)
endif(UNIX)

Then let CMake take care of the rest (when evaluated this is a real CMake
target. I am just setting some test builds up. Setting openbabel-2.lib always
felt very hackish, we should be making CMake do more of this for us,
especially as when we compile the targets are all CMake targets anyway.

Sorry I haven’t had much time to look at the changes you proposed. The Linux
installer sounds pretty good, but my aim in creating the superpackage was to
make a cross platform build. I think external projects better satisfy that
aim, but everything can be accomplished with this approach too.

If they diverge for a while, and your repo becomes a Linux centric version,
and I aim for a Mac/Windows centric version we can still pull them back
together. This is where git topic branches, and a branchy workflow really help
though, but that is another post.

Marcus

Konstantin_Tokarev · May 22, 2010, 8:11pm

That changes you introduced are only for Linux, and to be honest that
was never a massive target of mine as it already has lots of good
package managers.

But not so many of them allow choice of several versions, and no one is
able to install two versions of package simultaneously. People will be
able to install stable from repos and unstable from installer, or vice
versa. Also, they’ll be able to use software immediately after release
(Gentoo and Arch users are already in luck though:)

–
Regards,
Konstantin

mhanwell · May 24, 2010, 3:45am

On Friday 21 May 2010 10:39:01 Geoffrey Hutchison wrote:

On May 21, 2010, at 6:15 AM, Marcus D. Hanwell wrote:

now, I am convinced the most reliable way of doing this is to use CMake
config files, but that would require newer OB versions with these config
files. I will get to work in adding them though, as they tend to make
life simpler and the

The biggest concern here is with the trunk development version of OB, so
there’s no issue with “newer OB versions.”

I pushed a few small changes to the superbuild. They should sort out the
immediate issue. I have also committed some build system changes in Open Babel
trunk to export targets and make a config file. This will facilitate the use of
external projects should we wish to go down that route.

I took a quick look, without having access to a Mac at present it is tough to
test. I will hopefully get one soon, but until then the fix looked good on
Linux and gets rid of a lot of guess work in the build system, leaving CMake
to take care of that along with dependencies between targets.

Marcus

Louis_Ricard · May 24, 2010, 4:09pm

Hi Marcus.

This morning, I gave a try at compiling your avogadro-super. First removed all of OB
and avo in /usr/local. Using gcc-4.2.1 in MacOSX 10.6.3 and Python disabled,
compilation completes with no apparent error, but avo crashes on startup (report
enclosed). (git-1.6.4.2 and cmake-2.8.1)

I also tried in CentOS-5.5. There, I had to upgrade the packaged git to version 1.7.1
in order to be able to run “git submodule …” and cmake to version 1.8.1 in order
to complete cmake without error. Otherwise, works fine.

Regards,

Louis