Re: [Open Babel] Proposed Directory/Build Changes?

[Craig A. J. <cj...@em...>]

Hi Geoff,


> I'm looking for some input/feedback on a proposed change to the  
> directory layout and build environment.
>...
> What I'm proposing goes like this:
> 
> src/formats/  -- stays as-is, needs some changes to #include paths
> src/main.cpp  -- stays as-is, needs some changes to #include paths
> src/GUI       -- ditto
> src/fingerprints -- ditto
> 
> Everything else under src/ (i.e., the libopenbabel source and header)...
> Move to a new directory:
> lib/openbabel/ -- needs some changes to #include paths too
> lib/openbabel/math -- ditto

If I understand the problem, it's that the #include for a header uses "mol.h" internally, but has to be modified before it's installed, to read "openbabel/mol.h".

So my first questions is: Why?  In my opinion, headers should *not* use "openbabel/mol.h" at all.  If I recall, this was one of the big changes from OpenBabel 1.0 to 2.0, and I didn't understand the reason for it then.

This is exactly parallel to why we have namespaces in C++.  Back in my Daylight days, we had to name every single function in the Daylight Toolkit "dt_xxx()" or (for internal functions) "dy_xxx()", because names like "atom" were used by X Windows.  With C++, you use namespaces instead, and that frees you up to name your functions anything you like.

The correct way to do this is to use the "-I" directive in the Makefile, so that even if there's a system file named "mol.h", there's no confusion.  This is the Makefile equivalent of C++ namespaces: Get your include-path right, and there is no name-collision problem.

For example, there's a file called "atom.h" in the X-Windows library, a fact that has annoyed chemists for the last 20 years, but you just have to get the Makefile right, and it finds the correct one.

The real problem is that the OpenBabel headers should *not* use "openbabel/mol.h", but rather should  use plain "mol.h".  That would solve the problem that is prompting this reorganization.

There may be other good reasons to reorganize, but that's another topic.

Cheers,
Craig