oce-config.h should not be installed as is about oce

[mpictor]

Crap! I should have read this before committing cb7a159c8.

What is the workaround in the meantime? I tried to compile a program that uses opencascade, and compilation failed because oce-config.h couldn't be found. Once I installed it, compilation succeeded - but it uses CMake instead of Autotools.

[hsorby]

Is it not easier to hash define these out. These values are standard automake defines which are used when creating distributable packages are they not? They are not actually used to control available functionality within the library are they? The oce-config.h file is used to describe exactly what settings were used to generate the libraries if the defines above do not control functionality then defining them out when not needed could be a solution.

[mpictor]

I'm wondering if we can simply place the offending macro definitions inside
an #ifdef OCE_COMPILE, and then compile OCE with -DOCE_COMPILE

Edit: Don't use the "comment by replying to this email" feature, without deleting the text...

[dbarbier]

As we will move away from Autotools soon, there is no need to guess how to change oce-config.h.in, we can patch oce_config.h.cmake which is hand written.
I believe that it will be easier to rename variables,but your solution may also work.

[dbarbier]

Some context was missing from my initial report, let me clarify some things.
I co-maintain the Debian package of OpenCASCADE since 2008. This package is built for many architectures, and split into several pieces based upon upstream components:

• shared libraries (foundation, modeling, visualization, ocaf: 4 binary packages)
• development files for these components (4 binary packages)
• draw

First of all, we provide binary packages to users, which means that installed files have been generated on autobuilders, and not on user's machine. So we cannot ensure that oce-config.h will be identical if user rebuilds packages on her machine. This may be troublesome, but in practice it is not because very few macros are needed by installed headers.
On Debian, I decided to patch header files to not depend on any macro definition, see
http://git.debian.org/?p=debian-science/packages/opencascade.git;a=blob;f=debian/patches/drop-config-h.patch

This is possible in this context because, thanks to package dependencies, we can ensure that gl2ps and FreeImage are installed. And of course, our target is limited, we know which header files are installed on the system (for instance for iostream) and do not need macros.

Because of the last point, this approach does not work in OCE, we need a solution which also works on Windows, Mac, BSDs, etc.
The initial comment of this issue is not hypothetical at all, and is also explained in
http://sourceware.org/autobook/autobook/autobook_96.html
In order to prevent clashes between macros defined in oce-config.h and in the config.h file of a program which is built with Autotools and linked against OCE, the only solution is to change macro names, as explained in the URL above (if I knew it when I filed this report, things would have been much clearer ;))
With CMake, the solution is easier, we have a full control over macro names, as shown by Mark's changes.

Another insteresting read:
http://www.gentoo.org/doc/en/articles/autotools-practices.xml
Found those URLs after googling for "Autotools conflict config.h".

[dbarbier]

Fixed in bd395dc