On Sun, May 20, 2012 at 10:23 AM, Even Rouault
wrote:
> I think it is good time to discuss now what we want to allow, or not, for GDAL
> 2.0, as far as the C/C++ API is concerned.
Even,
My brief thoughts are:
* My objectives for GDAL/OGR 2.0 primarily revolve around
restructuring OGR to be clo
>
> A gold-plated GDAL 2.0 exists as something for us the developers, at least
> as it appears right now, to marvel at rather than provide real world
> improvements in functionality.
I think that the justification of the 2.0 in GDAL 2.0 should be mostly drived
by the need of implementing new rea
You should be linking against gdal_i.lib.
Marty
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of James Farrell
Sent: Monday, May 21, 2012 9:23 AM
To: Mateusz Loskot
Cc: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Micros
Thanks, Mateusz
I see the source code now. I'm linking against gdal.lib. Shouldn't
CPLStringLists's functions be in that library? Did I somehow build it
incorrectly?
Thanks again!
James
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.or
On Mon, May 21, 2012 at 09:06:06AM -0500, Howard Butler wrote:
>
> On May 20, 2012, at 12:23 PM, Even Rouault wrote:
> > -
> > Syntax of command line utilities
> > -
>
> I'd like to see some normalizat
Oops
This company (to which I am new) keeps multiple copies of the library in
multiple folders. I rather assumed we were linking against the ones in the
gdal folder, but I was wrong. Needed to update the library in a different
folder and it worked.
Thanks for your help
James
-Original Me
On 21 May 2012 16:23, James Farrell wrote:
> Thanks, Mateusz
> I see the source code now. I'm linking against gdal.lib.
> Shouldn't CPLStringLists's functions be in that library?
> Did I somehow build it incorrectly?
CPLStringLists is exported function.
AFAIK, it should be visible without any ex
On 21 May 2012 15:41, James Farrell wrote:
> I cannot find a definition for Count() anywhere.
>
> We are not using CPLStringList in our code, but there is other code within
> GDAL that uses it. Are we supposed to make our own Count() function? Where
> is this supposed to live?
Look at port/cpls
Not sure I'm doing this correctly, I don't see how to respond to a particular
thread in this forum...
I'm wrestling with the same problem as the thread in the subject line:
error LNK2019: unresolved external symbol "public: int __thiscall
CPLStringList::Count(void)const "
GDAL itself builds per
On 21 May 2012 15:06, Howard Butler wrote:
> Our contract has been with the C API users, not the C++ ones, and
> accordingly, I think we have carte blanche permission to do whatever we want
> with the C++ API. I for one hope this includes organizing our include file
> and installation layout.
On May 20, 2012, at 12:23 PM, Even Rouault wrote:
> Up to now, the signature of functions added in the GDAL/OGR C API has never
> changed, once they have been added.
This fact has at once been GDAL's strongest strength and its greatest weakness.
GDAL's ability to innovate has been hampered by t
As a programmer using GDAL/OGR, I do not think I mind if there are API
changes at major releases - especially, as with GDAL, where these are
infrequent - but might be annoyed during point releases. It is reasonable
to expect major new features and rationalisation at major releases, so the
burden o
Hi Even,
20.05.2012 21:23, Even Rouault написал:
Hi GDAL developers and users (actually, developers of other projects using
GDAL ;-)),
This issue was raised incidently in the "[gdal-dev] VRTComplexSource with a
LUT, proposal" thread at http://lists.osgeo.org/pipermail/gdal-dev/2012-
May/032872.h
13 matches
Mail list logo
