The Makefile has this line:
include $(MAKEFILEPATH)/CoreOS/ReleaseControl/GNUSource.make
so you will need the Darwin project CoreOSMakefiles-30. Working
backwards, GNUSource.make includes Common.make, which defines OBJROOT
to be /tmp/$(ProjectName)/Build. With this, I found the built
products in:
/tmp/SQLite3/Build/.libs/
The makefiles appear to be from a Project Builder makefile-based
project (does Xcode still support these?). Any, I was able to build
it outside of Xcode and it may work to create a project if you want.
(I didn't actually install the built product, so there may be issues
with that step.)
Here's another suggestion for you. Obviously you are going to be
interested in merging Apple's changes in with the latest SQLite
source. Subversion (and probably other SCMs) has some ability to
track a branch relative to a vendor distribution (i.e., the standard
SQLite distribution), which would help combine Apple's changes and
the changes from 3.1.3 to 3.2.5. I've never used that feature of
Subversion, so I can't offer much more at the moment.
Keep us posted, I'm curious to know how this goes for you.
Aaron
On Oct 28, 2005, at 11:36 AM, Steve Palmer wrote:
Has anybody tried building that though? If you download the files
from http://www.sqlite.org/cvstrac/tktview?tn=1240 and run make
from the root of the expanded folder then it will go through the
process of configuring and building, but I can't find the output
files anywhere. A search under the folder shows nothing seems to
have been created.
Interestingly, if you build from the SQLite3 folder, it will
generate the object files and place the libraries in a hidden .libs
folder but those all omit the new locking mechanism and hence the
final results don't work for me. Unfortunately I can't quite figure
out what is different.
Any ideas?
- Steve
On Oct 27, 2005, at 6:09am, Aaron Burghardt wrote:
You can take a look at what Apple has done for OS X here:
http://www.opensource.apple.com/darwinsource/10.4/SQLite-28/
Don't be mislead by the project name--it is SQLite 3. I haven't
studied it closely, but it should allow you to build exactly what
Apple shipped. The Makefile has references to locking callbacks,
so this might be relevant:
# add -DSQLITE_DEBUG=1 to enable lock tracing and other debugging
features
# you also need to set sqlite3_os_trace to 1 in SQLite3/src/
os_common.h
Extra_CC_Flags += -DASSERT_VIA_CALLBACK=1 -
DENABLE_LOCKING_CALLBACKS=1
HTH,
Aaron
On Oct 25, 2005, at 12:45 PM, Steve Palmer wrote:
What are those reasons and is there any expectation that they can be
made available as patches for folks who build SQLite privately? I
cannot use the libsqlite3.dylib that comes with Mac OSX 10.4
since my
application needs to run on 10.3.9 too and there is no equivalent
static version that I can find.
- Steve
On Oct 25, 2005, at 4:57am, [EMAIL PROTECTED] wrote:
Steve Palmer <[EMAIL PROTECTED]> wrote:
I'm currently investigating a problem with my application, SQLite
3.2.5 and a database located on a Mac OSX Server network share
that
does not seem to repro with the SQLite 3.1.3 that ships with
Mac OSX
4.1. Specifically if I place a SQLite database file on a folder
on a
remote network share and attempt to access it using the sqlite3
utility, I get different results.
Apple added special hacks to their release of SQLite 3.1.3 that
allow it to work on remote filesystems with broken file locking.
For various reasons, those hacks have not been incorporated into
the SQLite core, yet.
--
D. Richard Hipp <[EMAIL PROTECTED]>
