[sqlite] Re: developers mailing list, ignored patches

2007-03-04 Thread Adam Megacz

[EMAIL PROTECTED] writes:
>> I also printed out and signed the copyright papers and mailed them in.

> Your copyright release and your patches arrived in today's post.  
> The postmark is smeared somewhat but it does appear to say 
> "2? DEC 2006" (where the ? is illegible.)

> So from Oakland, CA to Charlotte, NC in only 62 days.  And one
> wonders why the nobody sends letters anymore

Heh, not surprising.

If you do get a chance to look at the filesystem detection additions,
I would appreciate hearing back on that.  I can try to break it out
into a separate patch from the autoconf stuff.

  - a

-
To unsubscribe, send email to [EMAIL PROTECTED]
-



[sqlite] Re: developers mailing list, ignored patches

2007-02-25 Thread Adam Megacz
The following message is a courtesy copy of an article
that has been posted to gmane.comp.db.sqlite.general as well.


[EMAIL PROTECTED] writes:
> It is true that I do not use autoconf much.  But I do use it now
> and then.  The main problem is that autoconf is broken on my
> SuSE 10.1 installation and I have not taken the time to try to
> fix it.

A few months ago, I posted a patch to make the autoconfigury deal with
HAVE_FSCTL and HAVE_STATFS_H, as well as add a configure option for
SQLITE_ENABLE_LOCKING_STYLE.

I also printed out and signed the copyright papers and mailed them in.

I never got a response on any of this; not even a "no thanks".

Could you please let me know what happened?  If the patch is
officially rejected, please say so.  It's pretty disheartening to go
to this trouble and be ignored.

  http://www.mail-archive.com/sqlite-users%40sqlite.org/msg20672.html

  http://www.sqlite.org/cvstrac/tktview?tn=2136
  (note that the first "remark" confuses this with something else)

Below is a copy of the patch updated to work against latest CVS.
Don't forget to run 'autoreconf' after applying.

I also have a patch which exposes a configure option for FTS1; I would
be happy to contribute it.

  - a


Index: Makefile.in
===
RCS file: /sqlite/sqlite/Makefile.in,v
retrieving revision 1.163
diff -u -r1.163 Makefile.in
--- Makefile.in 17 Feb 2007 14:46:31 -  1.163
+++ Makefile.in 25 Feb 2007 19:54:42 -
@@ -32,7 +32,7 @@
 # Omitting the define will cause extra debugging code to be inserted and
 # includes extra comments when "EXPLAIN stmt" is used.
 #
-TCC += @TARGET_DEBUG@ @XTHREADCONNECT@
+TCC += @TARGET_DEBUG@ @XTHREADCONNECT@ @ENABLELOCKINGSTYLE@
 
 # Compiler options needed for programs that use the TCL library.
 #
Index: configure.ac
===
RCS file: /sqlite/sqlite/configure.ac,v
retrieving revision 1.29
diff -u -r1.29 configure.ac
--- configure.ac17 Feb 2007 14:59:18 -  1.29
+++ configure.ac25 Feb 2007 19:54:42 -
@@ -217,6 +217,21 @@
 AC_SUBST(XTHREADCONNECT)
 
 ##
+# Do we want to allow different locking styles?
+#
+AC_ARG_ENABLE(locking-style, 
+AC_HELP_STRING([--enable-locking-style],[Enable different locking 
styles]),,enable_lockingstyle=no)
+AC_MSG_CHECKING([whether to allow connections to be shared across threads])
+if test "$enable_lockingstyle" = "no"; then
+  ENABLELOCKINGSTYLE=''
+  AC_MSG_RESULT([no])
+else
+  ENABLELOCKINGSTYLE='-DSQLITE_ENABLE_LOCKING_STYLE=1'
+  AC_MSG_RESULT([yes])
+fi
+AC_SUBST(ENABLELOCKINGSTYLE)
+
+##
 # Do we want to set threadsOverrideEachOthersLocks variable to be 1 (true) by
 # default. Normally, a test at runtime is performed to determine the
 # appropriate value of this variable. Use this option only if you're sure that
@@ -571,7 +586,35 @@
 # Redefine fdatasync as fsync on systems that lack fdatasync
 #
 
+AC_CHECK_HEADER([sys/statfs.h], [TARGET_CFLAGS="$TARGET_CFLAGS 
-DHAVE_SYS_STATFS_H=1"],)
+
 AC_CHECK_FUNC(fdatasync, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_FDATASYNC=1"])
+AC_CHECK_FUNC(fsctl, [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_FSCTL=1"])
+
+AC_CHECK_MEMBER(struct statfs.f_flags,
+  [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_STATFS_F_FLAGS=1"],,
+  [
+#include 
+#include 
+#include 
+  ])
+
+AC_CHECK_MEMBER(struct statfs.f_type,
+  [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_STATFS_F_TYPE=1"],,
+  [
+#include 
+#include 
+#include 
+#include 
+  ])
+
+AC_CHECK_MEMBER(struct statfs.f_fstypename,
+  [TARGET_CFLAGS="$TARGET_CFLAGS -DHAVE_STATFS_F_FSTYPENAME=1"],,
+  [
+#include 
+#include 
+#include 
+  ])
 
 #
 # Generate the output files.
Index: src/os_unix.c
===
RCS file: /sqlite/sqlite/src/os_unix.c,v
retrieving revision 1.117
diff -u -r1.117 os_unix.c
--- src/os_unix.c   6 Feb 2007 11:11:08 -   1.117
+++ src/os_unix.c   25 Feb 2007 19:54:44 -
@@ -52,6 +52,9 @@
 #ifdef SQLITE_ENABLE_LOCKING_STYLE
 #include 
 #include 
+#ifdef HAVE_SYS_STATFS_H
+#include 
+#endif /* HAVE_SYS_STATFS_H */
 #include 
 #endif /* SQLITE_ENABLE_LOCKING_STYLE */
 
@@ -479,6 +482,52 @@
 #define fcntl lockTrace
 #endif /* SQLITE_LOCK_TRACE */
 
+#ifdef SQLITE_ENABLE_LOCKING_STYLE
+/**
+ *  Check to see if the OS fcntl() byte-range locking call will "lie"
+ *  to us and grant a lock that is not enforced.  This happens notably
+ *  with files in AFS (OpenAFS client <1.5.0, all OSes but Linux).
+ *
+ *  Returns zero if byte-range locks appear to work as expected.
+ */
+static int testProcessLockingBehavior(int fd_orig){
+  int fd;
+  int result;
+  struct flock lock;
+  
+  fd = dup(fd_orig);
+  if( fd<0 ) return 1;
+  memset(, 0, sizeof(struct flock));
+  lock.l_type = F_WRLCK;
+  lock.l_len = 1;
+  lock.l_start =