monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?


From: Ralf S. Engelschall
Subject: Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
Date: Sun, 6 Apr 2008 08:53:27 +0200
User-agent: Mutt/1.5.17 OpenPKG/CURRENT (2007-11-01)

On Sat, Apr 05, 2008, Markus Schiltknecht wrote:

> Ralf S. Engelschall wrote:
>> The alternative is to place a full SQLite build-environment 1:1 into
>> sqlite/ and also run its own "configure" step during Monotone's
>> "configure" step.
>
> Yes, that's what I've been talking about and what nvm.library-build is all
> about.
>
>> No, the amalgamation "sqlite3.c" file is not really pre-processed in
>> the meaning of the C pre-processor. But it is pre-processed in the
>> meaning of the Lemon parsor generator, etc. It is more or less just
>> a concatenation of the *.c source files (where parse.c is also used
>> instead of parse.y, etc).
>
> Aha, okay. Do you think we should use that, as recommended by sqlite.org?

Hmmm... well, I think it would not matter very much whether we use the
amalgamation or the regular SQLite. The amalgamation perhaps has the
advantage that it is less "intrusive" to the Monotone source tree and
that a theoretic compiler code optimization advantage exists.
>
>> Ok, I've it running. I dropped sqlite/*, added sqlite3.[ch] and
>> adjusted the Monotone build-environment for this. I'm now checking the
>> functionality under run-time (especially via the test suite)...
>
> Cool. Already gotten results from the testsuite?

Yes, everything works except for one(!) particular strange test which
tests whether SQLite can write to a non-writeable directory, etc. I've
already looked at it and I think it doing some assumptions which are no
longer true with SQLite 3.5's new OS abstraction layer and so has to be
removed IMHO. But I've to look at this again and really find the real
reason in order to not do the wrong thing here.

> Do you mind publishing your changes? That might get useful in
> nvm.library-build. Maybe we can upgrade to sqlite 3.5 first, then propagate
> nvm.library-build?

I've still not looked at nvm.library-build in detail but from the
commits it looks you are reorganizing the libs there. Looks fine, too.
I'll try to upgrade to SQLite 3.5 ASAP and then you can propagate
nvm.library-build, too. Ok?

                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com





reply via email to

[Prev in Thread] Current Thread [Next in Thread]