263211 - sqlite3 and storage landing

Status: RESOLVED FIXED

(Core :: SQLite and Embedded Database Bindings, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Bug for landing of sqlite3 and mozStorage on trunk.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: storage-configure.patch

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: storage-sqlite-makefile.patch

Makefile.in for sqlite3, if someone can look over and make sure it looks sane

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: storage-configure.patch

Updated with darin's comments..

* --enable-new-storage-api became --enable-storage
* MOZ_NEW_STORAGE became MOZ_STORAGE
* added MOZ_STORAGE to autoconf.mk.in, so we can use it in makefiles for
selecting which components to build
* added MAKEFILES_storage to standalone section of allmakefiles.sh

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 161299 [details] [diff] [review]
storage-configure.patch

(I just noticed the tab vs. space bit in allmakefiles.sh -- fixed locally)

Comment 5

[Mike Shaver (:shaver emeritus)]

Comment on attachment 161299 [details] [diff] [review]
storage-configure.patch

Please file a bug on --with-system-sqlite3 and cite it in the XXX comment.

Taking darin's comments as r, marking sr myself, hoping for the mercy of cls's
wise and benevolent judgement.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ok, storage is landed -- need to get storage added to SeaMonkeyAll (and
db/sqlite3, if necessary).

Comment 7

[Benjamin Smedberg]

Please do not add things to SeamonkeyAll, use client.mk instead.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #7)
> Please do not add things to SeamonkeyAll, use client.mk instead.

I'm not sure where I'd put it in client.mk -- are you suggesting another extra
CVSCO_* thing to pull?  I guess we can go that route, but considering that
storage is/will be used by necko and other core bits, SeaMonkeyAll seems to be a
better place for it and would create less confusion (e.g. a SeaMonkeyAll pull
without also pulling storage will fail once the bits get flipped).

If client.mk is still the right way to go, though, then I'll make a patch and go
that route.

Comment 9

[Benjamin Smedberg]

Just change
MOZ_CO_MODULE := SeaMonkeyAll
to
MOZ_CO_MODULE := SeaMonkeyAll mozilla/db/sqlite3

Also see bug 261232

Comment 10

[Darin Fisher]

> Please do not add things to SeamonkeyAll, use client.mk instead.

Why?  Isn't this the purpose of CVS modules?  Shouldn't we have one base CVS
module that contains all the core stuff?  Are you suggesting that we may at some
point refactor and use a different base module?  Surely you argee that storage
will be a core gecko component.


> MOZ_CO_MODULE := SeaMonkeyAll mozilla/db/sqlite3

NOTE: we also will need to update the bonsai query that tinderbox uses, etc.,
which IIRC involves tweaking the meaning of some CVS module (MozillaTinderboxAll?).

Comment 11

[Benjamin Smedberg]

The problem with CVS modules is that once you add something, you can never
remove it without breaking historical tags. SeaMonkeyAll already has problems
where we have to keep files around just to keep CVS pulls from complaining. cls
and I are planning to make SeaMonkeyAll obsolete, and bug 261232 is a step in
that direction. It already contains 

> NOTE: we also will need to update the bonsai query that tinderbox uses, etc.,
> which IIRC involves tweaking the meaning of some CVS module
(MozillaTinderboxAll?).

That is fine, it is not used for pulls, and we can add/remove directories/files
there with impunity.

Comment 12

[Benjamin Smedberg]

Oops, it already contains directories we don't need/want to pull for
firefox/sunbird/etc (mailnews, in particular).