[gdal-dev] include paths and cmake

Even Rouault even.rouault at mines-paris.org
Fri Nov 4 16:58:58 EDT 2011

Le vendredi 04 novembre 2011 21:10:41, Mateusz Łoskot a écrit :
> On 4 November 2011 13:06, David Burken <dburken at comcast.net> wrote:
> > If you move the includes around on the install then
> > it complicates the include paths when building against the code tree
> > versus building against an installed version
> The headers location is already different for installed and repo source
> tree. One location for the former, at least four locations passed with
> -I/... for the latter.

As announced in its subject, this discussion is obviously mixing 2 different 
topics :
* cmake-based build system for GDAL
* changing include paths

This raises the questions of what aims and constraints the cmake effort will 
have. Some obvious observations based on this thread :
1) If you move header files in the source tree, this would certainly break the 
current build system with its hand-made makefiles, unless changes are made to 
fix it.
2) If you install the public header files elsewhere in the "install" target of 
the cmake build, then, depending on how GDAL has been built, the installed 
layout will be different. Which would be nightmarish for users if both build 
system co-exist for some time.

To sum it up, the addition of the cmake build system alone can be a non-
breaking and self-contained effort, whereas the topic of changing include paths 
is potentially a "breaking" change that would impact all build systems. Of 
course, this can be a non-issue if both efforts are targetted for a mythical 
GDAL 2.0 that would also throw away the current build system to replace it 
with the cmake one.

> Best regards,

More information about the gdal-dev mailing list