[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