2011/11/4 Mateusz Łoskot <mate...@loskot.net>:
> On 4 November 2011 13:06, David Burken <dbur...@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.
But wouldn't it be nice if it weren't like that? =)
If there was only one include location for both development and
release, and the relative paths from that location were the same, then
it makes setting up project/configuration files easier and it makes it
easier for IDE's to understand the code (especially for supporting
autocompletion).
To be explicit, you would add a directory called "gdal" to the main
SVN checkout directory. All the source code makes up the gdal library
would be moved into that "gdal" directory, e.g:
myGdalCheckout
gdal
alg
frmts
gcore
ogr
port
apps
bridge
... etc
All header files have their #includes altered to be relative to the
root directory (the SVN source checkout, for development), e.g:
#include "gdal/gcore/gdal.h"
#include "gdal/ogr/ogrsf_frmts/generic/ogr_gensql.h"
(Noting again that although the gdal implementation files tend to
include files deep in the directory tree, the includes for interfaces
tend to be near the root of the tree.)
When compiling, only one include directory needs to be supplied
whether you're a gdal developer (the SVN checkout dir), or a user of
the library (the system's regular include directory). The changeover
is a hassle, but once done it makes your development environment much
easier to set up, and configuration files easier to maintain.
Cheers,
- Dan
P.S. If you really want the interface headers to be easy to include,
move the commonly used interface headers into the new gdal directory.
Since the *.cpp files will all use relative paths from the source
tree's root for their #includes, their associated header files are
easy to find, even if they're not in the same directory. Thus, a user
of the library could have:
#include "gdal/gdal.h"
#include "gdal/cpl_port.h"
rather than
#include "gdal/gcore/gdal.h"
#include "gdal/ports/cpl_port.h"
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
