2011/11/4 Mateusz Łoskot :
> On 4 November 2011 13:06, David Burken 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 fo
Le vendredi 04 novembre 2011 21:10:41, Mateusz Łoskot a écrit :
> On 4 November 2011 13:06, David Burken 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
On 4 November 2011 13:06, David Burken 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.
O
Hello All:
Either way should work with frameworks. The typical is something of the form:
collapsed:
gdal/
but this is fine as well
not collapsed:
gdal/…./someheader.h
the one that is not collapsed will require a custom cmake process to make the
directory structure in the gdal.framworks.
On Fri, Nov 4, 2011 at 6:06 AM, David Burken 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 t
Hello All:
For include paths of the form gdal/cpl_config.h would lead easier to do MAC
Framworks where one can create a gdal.framework and use the gdal/ convention.
Take care
Garrett
On Nov 3, 2011, at 5:24 PM, David Burken wrote:
> Mateusz,
>
> Just wondering if you've thought about namespa
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
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
On 11-11-03 05:31 PM, Mateusz Łoskot wrote:
On 3 November
On 3 November 2011 22:05, Even Rouault wrote:
> Le jeudi 03 novembre 2011 22:33:38, Mateusz Łoskot a écrit :
>> On 3 November 2011 21:26, Kyle Shannon wrote:
>> > I believe that is on the 2.0 changes list, or something along those
>> > lines. See:
>> >
>> > http://trac.osgeo.org/gdal/wiki/GDAL20
Le jeudi 03 novembre 2011 22:33:38, Mateusz Łoskot a écrit :
> On 3 November 2011 21:26, Kyle Shannon wrote:
> > I believe that is on the 2.0 changes list, or something along those
> > lines. See:
> >
> > http://trac.osgeo.org/gdal/wiki/GDAL20Changes
> >
> > under House Keeping issues
>
> Grea
On 3 November 2011 21:26, Kyle Shannon wrote:
> I believe that is on the 2.0 changes list, or something along those lines.
> See:
>
> http://trac.osgeo.org/gdal/wiki/GDAL20Changes
>
> under House Keeping issues
Great news!
Frank, Even,
Can I set http://trac.osgeo.org/gdal/ticket/3435 with 2.0
On 3 November 2011 21:24, David Burken wrote:
>
> Just wondering if you've thought about namespacing the include paths? That
> is:
>
> #include "cpl_config.h"
> #include "gdal_frmts.h"
>
> Becomes:
> #include
> #include
>
> Or (flattened):
> #include
> #include
David,
I thoroughly agree.
He
Sent: Thursday, November 03, 2011 3:24 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] include paths and cmake
Mateusz,
Just wondering if you've thought about namespacing the include paths?
That is:
#include "cpl_config.h"
#include "gdal_frmts.h"
Becomes:
#include
Mateusz,
Just wondering if you've thought about namespacing the include paths?
That is:
#include "cpl_config.h"
#include "gdal_frmts.h"
Becomes:
#include
#include
Or (flattened):
#include
#include
This would make installs / uninstalls cleaner. Say your install prefix is:
/usr/local
14 matches
Mail list logo