Re: [sqlite] Re: Cursor naming conflict

[Jeff Edwards]

Your way is certainly one way of doing it, but the other way I suggest 
should be able to be done, especially since it gives us the ability to 
"poke" around accessing some internal information for which no public 
API had been provided. . . which has been a great help to our plugin.  
There is also the question of compiling for windows with the same 
source, but not the same library on the OSX machine.  It is far more 
convenient to do this from the same single project. . . on a single 
machine.

The only naming conflict is "Cursor"   . . .  this is the only one I am 
asking to change.

Jeff Edwards

On 07/09/2004, at 10:12 AM, Will Leshner wrote:
On Sep 6, 2004, at 7:03 PM, D. Richard Hipp wrote:
The "Cursor" object in SQLite is an internal name.  It does not appear
anywhere in "sqlite.h" or "sqlite3.h".  Since the neither XCode nor 
Carbon
are required to compile SQLite, the definition of Cursor should not 
appear
in any of the files included by SQLite either.  So there should be no
conflicts.  If you are getting conflicts, I think the blame belongs to
the build environment, not SQLite.  I think it ill-advised to go 
around
altering names in SQLite in order to work around problems in obscure
build environments such as Code Warrior for Mac OS 9.

I agree. Furthermore, I build SQLite for OS 9 and OS X in CodeWarrior 
I don't have any conflict with QuickTime. What I do is build to a 
separate library with SQLite and then I include that library in my 
main projects. I've never had any problem with it.