[gdal-dev] include paths and cmake

[David Burken]

On 11/03/2011 09:15 PM, Daniel Morissette wrote:
> Personally I like the idea. I'd probably go for the flattened version 
> unless there is a good reason to carry a bunch of sub-directories around.
>
> If there are any serious arguments against doing this then I'd like to 
> hear them.
>
> Daniel
>
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

>
> On 11-11-03 05:31 PM, Mateusz Łoskot wrote:
>> On 3 November 2011 21:24, David Burken<dburken at comcast.net>  wrote:
>>>
>>> Just wondering if you've thought about namespacing the include 
>>> paths?  That
>>> is:
>>>
>>> #include "cpl_config.h"
>>> #include "gdal_frmts.h"
>>>
>>> Becomes:
>>> #include<gdal/port/cpl_config.h>
>>> #include<gdal/gcore/gdal_frmts.h>
>>>
>>> Or (flattened):
>>> #include<gdal/cpl_config.h>
>>> #include<gdal/gdal_frmts.h>
>>
>> David,
>>
>> I thoroughly agree.
>> Here is related ticket: http://trac.osgeo.org/gdal/ticket/3435
>>
>> IMHO, current way of installing headers is becoming inconvenient and
>> unacceptable...
>>
>>> I realize this would be a big change.  Just thought since you're 
>>> taking the
>>> plunge on cmake it's something to consider.
>>
>> Yes, but I'm not a decision maker.
>> I can only encourage to collect more critical mass and nudge GDAL PSC
>> about this idea.
>>
>> Best regards,
>
>