[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