On Tue, Mar 04, 2008 at 02:02:33PM -0600, Norm Jacobs wrote: > Nicolas Williams wrote: > >Well, some SFW components already roll their own build/install parts, as > >I am doing. I predict that we'll see a lot odd things in the SFW > >consolidation. > > I would like to see us (the c-team) rein this in where possible. If > everyone rolls their own we are going to end up more than just neck > deep in it.
They're going to have their chance to do just that this afternoon :) > >It would help if FOSS projects had guidelines that they could, and > >hopefuly would, follow that would make integration into our SFW > >consolidation easier. > > Agreed, it's been on my list of things that I would like to get to real > soon now. I have integrated and updated several things in the SFW gate > and kept track of various pitfalls. I have an upcoming integration that > simplifies some of this and could serve as the poster child for a more > uniform approach. Hmm, I'm not talking about guidelines for folks integrating FOSS into SFW, though we need that too (and I've said so before). I'm talking about guidelines that FOSS communities could follow that would make it easier for folks integrating their projects into SFW. > >Maybe, but Dr. Hipp likes it this way (he generally recommends > >statically linking libsqlite3 into apps). That's fine as general advice > >to SQLite3 consumers, but within Solaris / OpenSolaris, that's not > >appropriate. > > > >Now, if I can get the SQLite3 community to accept patches that are > >intended for use only by the SFW consolidation, then I'll pursue that > >approach. I'll ask off-line. > > > The patches we are talking about should *not* be Solaris specific. If they'll accept generic ones, then sure, and I'll even make such patches. > Simply supplying the fixes to drink the whole pitcher of > libtool/automake/autoconf koolaid probably simplifies their build and > solves the various issues that you have been trying to work around in > their current build system. They will not stop using the "amalgamation" approach, I'm certain of that. So the build will not be simplified -- it will only grow an option to do things "the Solaris way." > >>I tried not to duplicate comments that have already been made. > >> > >>usr/src/lib/sqlite3/Makefile.sfw: > >> lines 71-81: > >> > >> Do you really want to deliver the extra debugging code via > >>--enable-debug? > >> > > > >It gets you the ability to trace the SQLite VM. OTOH, there's a comment > >in the code about performance going faster if one defines NDEBUG, so I > >may want to add -DNDEBUG=1 here. > > > >Alternatively I could omit VM tracing. > > > If you have a good reason for including --enable-debug, by all means, > keep it in. I was pointing it out because I wanted to make sure that it > wasn't an oversight. I'll re-think this. In particular I'll try to see if I can get VM tracing while also defining NDEBUG=1. > >>usr/src/lib/sqlite3/Makefile.in.diff: > >> Your patch to their build system is Solaris specific. It would be > >> preferable to make a more generic set of fixes that you send > >> upstream so that we have a chance of not having to create a new > >> patch if/when we resync with the upstream project. > >> > > > >Yes, but see my comments above. > > > If the patch isn't going back upstream, it's more work later. There's no way I can negotiate a patch with the upstream community and get this into SFW in time. I _can_ stop insisting on linking the sqlite3 executable and the Tcl plug-in with libsqlite3.so, and get back to that later. I'll let the SFW c-team decide this today. > >However, it turns out that the c-team is mighty uncomfortable with the > >sqlite3 use of readline, so I'm going to remove it. I tried > >libeditline, and that works with minimal changes to shell.c, BUT, I > >can't get history to work -- only line editing works. So I'm going to > >remove readline and I'm not going to add editline support. > > > Command line editing without the history still has some value so you > might still consider > using libeditline. I don't want to inadvertently introduce bugs here. So I will do this later. Nico --
