On Thu, Jan 15, 2009 at 12:14 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Greg Stein wrote:
>> On Wed, Jan 14, 2009 at 18:21, Justin Erenkrantz <jerenkrantz_at_apache.org> wrote:
>>> ...
>>> In order to use a static version, we have to rename all symbols to
>>> avoid conflicts as APR-util can also bring in sqlite. Therefore, we
>>
>> Nope... note the use of SQLITE_API defined as "static". All of the
>> sqlite functions are static to libsvn_subr/sqlite.c. No naming
>> contention at all!
>>
>>> have now introduced symbol/version collisions that can cause failures
>>> at run-time and indeterminate behavior.
>>>
>>> FWIW, I was already working on a patch to do the external config when
>>> ./sqlite exists - as no one added ./sqlite bundled-support to
>>> configure. IMO, that's a far more elegant solution... -- justin
>>
>> This was a first step to get svn working in the presence of an old
>> system sqlite. Obviously, it didn't work all that well for some
>> definition of "everybody".
>>
>> I'd prefer to see an amalgamation build over a ./sqlite build. Tho I
>> guess with the latter, it can be independently rev'd independent of
>> what amalgamation we include into our build.
>>
>> I'm curious about the ENOTSUP error though. I thought sqlite was very portable.
>>
>> Anyways... looks like a blend of restoring-autoconf and the amalg
>> build should do the trick. Just needs some volunteers...
>
> Here's what I'd like to see:
> * keep amalgamation ability, but ship the actual amalgamation file in -deps and
> install it in the correct place during configure
> * resurrect the link-to-system-library ability, have an officially recommended
> minimum version (preferably something like 3.5.0 for the time being)
>
> I can take a look over the next couple of days, but it may be slow going as I
> reteach myself m4. Justin, if you think it'd be helpful, would you might
> posting your patch-in-progress?
>
IMHO compiling and linking to internal SQLite is good approach.
Working copy often shared between different clients on different
operating systems. Gaurantee that _all_ clients linked with the same
SQLlite version is not easy task.
We had similar situation with BDB. And even it's repository users
often have problems that BDB compiled with different settings and
corrupts or cannot open repository
Also internal SQLite makes building of Subversion is much easier,
especially on Windows.
We can fix symbol collision with APR-util with simple python script
that adds prefix to amalgamated SQLite file.
Just my 20 cents.
--
Ivan Zhakov
VisualSVN Team
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1024936
Received on 2009-01-14 22:45:48 CET