On Feb 23, 2009, at 9:15 AM, P Kishor wrote:
> Ok, thanks William. I started again with BSD Dynamic Library template,
> and this time I got only one error... a warning about an unused
> variable 'err' on line 26510 of sqlite3.c. That line reads
>
> 26509> /* if mkdir fails, handle as lock file creation failure */
> 26510> int err = errno;
>
> (hence, cc-ing this message to the sqlite list)
>
unused vars - harmless.
> But, it did build. Now, of course, since I asked for just a BSD
> Dynamic Library, I got a libsqlite.dylib in the Products folder. I
> didn't get my usual sqlite3 shell binary, so does that mean I have to
> create another Xcode project with the Standard Command Line Tool
> template for that?
No, just make a new target in the project, BSD Shell Tool (and note
the naming inconsistency - the other template called it "Standard
Command Line Tool"). The template doesn't limit you to just the kind
of binary it starts with.
Add the sqlite executable source to this one, and drag in the sqlite
library from the Products group to link them. For dependency sanity,
drag the library target to the executable target also. This way all
you need to build is the executable target, and that will
automatically build the library target.
Something like:
libsqlite
compile
sqlite3.c
sqlite
libsqlite (target dependency)
compile
shell.c
link
libsqlite.dylib
> Also, is there an equivalent of 'sudo make install' for Xcode that
> actually files all the sqlite3 bits and bobs in the correct places?
>
I don't think so. There are some variables and steps mentioning
installation, but I think that's only for: 1) linking (ie the
install_name of a library) and 2) "installation" into the build
products folder during compilation.
Xcode is geared towards building Mac software, where it's a package,
so "installation" is simply dragging the package to its destination.
unix features seem to be for supporting Mac software.
> Of course, I can do all this without any problem from the command
> line, so this is more an exercise in learning Xcode.
>
Though doing it in Xcode means you can use the Xcode debugger, if
you're interested in that. You can attach external executables to a
project for use in the debugger, but they won't have a connection to
their sources for easy access to fix a problem.
Xcode has its uses in unix-based software, but it's hard to maintain
synchronization with the source, especially on big projects like GRASS
or where sources are added and deleted a lot. Optional components of
a project can't be automated easily, there are no conditional targets
in Xcode. Only code that is conditionalized on a macro can be made
optional.
I went Xcode crazy for a while with my frameworks and GRASS and Qgis,
but quickly gave it up. Though I just became the maintainer of a new
Xcode project in the Qgis source, we'll see how that goes...
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
