Re: [sqlite] Re: Cursor naming conflict
Jeff, There are several solutions to this naming conflict: 1. Don't use the Carbon headers as your prefix file. Name conflict solved. Instead you can create your own prefix file and include only the headers/symbols you need. 2. Build a static library of sqlite and link to that. This is the way I prefer to do things nowadays as it makes "larger" projects easier to manage and faster to (re-) build. HTH, - Rob Laveaux Pluggers Software Thijssestraat 203 2521 ZG Den Haag The Netherlands Email: [EMAIL PROTECTED] Website: http://www.pluggers.nl
Re: [sqlite] Re: Cursor naming conflict
I did not mean to send this unfinished bit. On 07/09/2004, at 10:50 AM, Jeff Edwards wrote: I also labour under the 4D API plugin architechture which prefers that i do it in this.
Re: [sqlite] Re: Cursor naming conflict
so you have a separate project to compile the windows library . . . . Look . . I am not saying your way is wrong, but my way is less time consuming assuming I don't have a naming conflict. If it is too much trouble for Dr Hipp to change the single name that is causing the problem, then so be it, but the arguments about obscure development environments and ignoring valid way to compile simply is not valid. I also notice that there has been some confusion by Dr Hipp in mixing up the operating systems asserting that I am compiling for OS9 (I noticed that the email I sent to Dr Hipp and published by him on the list has a portion of my words edited from macosx to Mac). I also labour under the 4D API plugin architechture which prefers that i do it in this. . . . . . . I am much more interested in getting the Open command bug getting fixed. On 07/09/2004, at 10:34 AM, Will Leshner wrote: On Sep 6, 2004, at 7:27 PM, Jeff Edwards wrote: There is also the question of compiling for windows with the same source, but not the same library on the OSX machine. Actually, I do use the same source. I just make a Windows library in CodeWarrior.
Re: [sqlite] Re: Cursor naming conflict
On Sep 6, 2004, at 7:27 PM, Jeff Edwards wrote: There is also the question of compiling for windows with the same source, but not the same library on the OSX machine. Actually, I do use the same source. I just make a Windows library in CodeWarrior.
Re: [sqlite] Re: Cursor naming conflict
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.
Re: [sqlite] Re: Cursor naming conflict
On Sep 6, 2004, at 7:19 PM, Jeff Edwards wrote: We agree with you with the scenario that you build the sqlite library and then link it into a project, however in our scenario, which does not appear to be obscure, we take the entire sqlite source code and directly compile it into our project. Under this scenario, the internal headers are visible and do create conflicts. Just to reiterate, we are using OSX, not OS9. The problem appeared in both xcode and code warrior, and x code is not an obscure development framework. But why can't you just build SQLite as a separate library?
Re: [sqlite] Re: Cursor naming conflict
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.
