Infer information about the source tree from DUNE-CMake's config mode files

[rolk]

OPM cannot include DUNE-CMake in config mode because it also needs information about which definitions that should be added to config.h, so that the DUNE headers is preprocessed identical in all libraries.

The current version simply uses the same probe routines as for the Autotools version, with some additional hints to guess the source directory from the location of the binary files.

An improvement to this would be to include the config mode files ourselves to first gather more information about where the source tree is located. The PkgConfig files cannot be used, as they point to the intended install location of the library instead of the build tree.

[blattms]

On Tue, Mar 19, 2013 at 04:56:31PM -0700, Roland Kaufmann wrote:

An improvement to this would be to include the config mode files
ourselves to first gather more information about where the source
tree is located. The PkgConfig files cannot be used, as they point
to the intended install location of the library instead of the
build tree.

There are two package config files: one in ${PROJECT_BINARY_DIR} and one
in ${PROJECT_BINARY_DIR}/cmake/pkg/. Only the latter is meant for
installation. The previous contains the definitions for using the
module uninstalled.

BTW: I did not have any problems using the DUNE's cmake modules as
dunecontrol is smart enough to use the correct location for
-D<dune_module>_DIR and OPM seems to find them with its find_package
call. Regarding the definitions this should be same picture as for the
DUNE modules with auto-tools. In both cases OPM does not rely on the
provided build infrastructure but uses its own tests.

I admit that this is not the ideal case, but it should suffice for the
release. Later on, making OPM real DUNE cmake modules is probably
preferable.

[rolk]

two package config files: one in ${PROJECT_BINARY_DIR} and one in ${PROJECT_BINARY_DIR}/cmake/pkg/. Only the latter is meant for installation. The previous contains the definitions for using the module uninstalled

Configured like this:

dune-common/bin/dunecontrol --builddir=build-autotools --configure-opts='--enable-shared' all

then run:

env PKG_CONFIG_PATH=dune-common/build-autotools/ pkg-config --cflags dune-common

yields -I/usr/local/include.

This is r7427 from https://svn.dune-project.org/svn/dune-common/branches/release-cmake-2.2

[blattms]

On Wed, Mar 20, 2013 at 07:11:53AM -0700, Roland Kaufmann wrote:

two package config files: one in ${PROJECT_BINARY_DIR} and one in ${PROJECT_BINARY_DIR}/cmake/pkg/. Only the latter is meant for installation. The previous contains the definitions for using the module uninstalled

env PKG_CONFIG_PATH=dune-common/build-autotools/ pkg-config --cflags dune-common

Actually I thought you were talking about CMake's package config files
(e.g. dune-common-config.cmake) and not about those of pkg-config. For
pkg-config you are correct of course.

This is not special to the cmake branches. It is the same for the
official version.

[bska]

Is this still an issue and, if so, is there something that can be done about it?

[rolk]

Is this still an issue and, if so, is there something that can be done about it?

Yes, it is still an issue; no, we don't have to do anything because it works as it is now; yes, we can do something about it; but no, no-one wants to spend time on it. So, in conclusion, if you want to clear out the issue list before the release, this should probably just be closed as won't-fix.

[bska]

if you want to clear out the issue list before the release, this should probably just be closed as won't-fix.

I'm not particularly hell-bent on clearing the list, but I do want to understand/know the status of most of the issues. A "won't-fix" could be the best solution, but I'll leave it open for now. Thanks for the update!

[atgeirr]

I'll close this as won't fix since we quite clearly do not have to fix this and will not spend any effort on it.