Nicolas Williams wrote:
> On Tue, Mar 04, 2008 at 12:21:43PM -0600, Norm Jacobs wrote:
>
>>> If I make no other changes then I don't need to make the above changes
>>> to avoid getting the .libs directory in the runpath. It is possible
>>> that the changes you suggest + the changes I was using will do what I
>>> wanted, but I ended up pursuing a much simpler approach, which you can
>>> see at the current webrev:
>>>
>>> http://cr.opensolaris.org/~nico/webrev-sqlite3-sfw-the-3rd/
>>>
>>>
>> I guess that the biggest issues with this approach is that it is
>> relatively foreign to how many of the other SFW components build.
>>
>
> 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.
> 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.
>>> The SQLite community has a penchant for static linking. For one thing
>>> it means that you're not dependent on someone else possibly changing
>>> versions of SQLite on you, and for another it means slightly faster
>>> code. But we're talking about integrating SQLite for Solaris consumers,
>>> so dynamically linking with libsqlite3.so is the right answer here.
>>>
>>>
>> I guess, to me, it seems like more of a flaw in their build system
>> that should be rectified. If I would like to build and deliver shared
>> libraries, there is no reason that anything in the sqlite code base
>> should be statically linking in the objects already delivered in it's
>> own shared libraries.
>>
>
> 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.
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.
>> 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.
>> 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.
>> Enabling the readline support is probably a good thing, but I have two
>> "issues" with it. First, your ARC case specifically called out that
>> you would be excluding this support. Second, how does this impact the
>> licensing / copyright files that you are using in the packages? We
>> may need counsel to weigh in and provide some clarity :-\ .
>>
>
> I discovered that readline was available in the gate after the ARC case
> approval. My intention was to send a note to the case about this.
>
That works for me.
> 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.
-Norm
