[gdal-dev] include paths and cmake

Garrett Potts potts at cfl.rr.com
Fri Nov 4 14:39:30 EDT 2011


Hello All:

Either way should work with frameworks.  The typical is something of the form:

collapsed:

gdal/<headers>

but this is fine as well


not collapsed:

gdal/<path>…./someheader.h

the one that is not collapsed will require a custom cmake process to make the directory structure in the gdal.framworks.  If it's collapsed then cmake's framework support will handle it more easily when doing a framework layout on MACs.


Take care

Garrett
 
On Nov 4, 2011, at 11:18 AM, Dan Homerick wrote:

> On Fri, Nov 4, 2011 at 6:06 AM, David Burken <dburken at comcast.net> wrote:
>> Keeping the sub directories allows you to develop off checked out code base
>> with one include path.  You could do that with flattened path but you would
>> have to move the headers in your code tree.  I'm all for that but it's
>> really not up to me.   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.  I hope that makes sense.  Many
>> packages separate the includes in their source tree, e.g. geos, ossim,
>> opencv.  The source tree includes mirror the installed include tree.  So
>> it's less complicated and this makes for easy installs / uninstalls.
>> 
>> Dave
> 
> I'm in favor of not flattening the include paths in the installed
> version, for just the reasons that Dave listed. In my experience,
> making the installed paths different than the source tree has little
> added value for the user, while adding developer headache. The user
> doesn't generally need to include very many files, and those files
> tend to be near the root of the tree anyways.
> 
> Cheers,
> - Dan
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



More information about the gdal-dev mailing list