I took a look at your webrev and have some questions/comments...
Does SUNWsqlite need to declare any dependencies outside of the common
depend file in the gate?
usr/src/lib/Makefile
Are you missing a dependency for "sqlite: tcl"?
usr/src/lib/sqlite3/Makefile.sfw
You use the same configure options for your 32 and 64 bit
config.status targets. You might want to put them in a common
variable (CONFIGURE_OPTIONS) and call "./configure $(CONFIGURE_OPTIONS)"
You shouldn't need -R/usr/lib and -L/usr/lib or -R/usr/lib/64 and
-L/usr/lib/64, but you should probalby have -L$(ROOT)/usr/lib or
-L$(ROOT)/usr/lib/64 depending on if you are building the 32 or 64
bit target.
Be sure that you are linking against the TCL in the gate instead of
build system so we don't end up with a mismatch if/when TCL upgrades
at some future date.
You appear to be staging your install and cherry picking the bits
from your staged area. You might consider setting DESTDIR=$(ROOT)
and INSTALL to $(SRC)/tools /install-proto and installing your bits
directly into the proto area. It is bound to be slightly more
involved than simply "cd $(VER) ; make ... install" particularly
because libtool installs it's own turds that you should probably not
deliver, but it will most likely save some copying of data and less
likely to miss something.
usr/src/lib/sqlite3/install-sfw
The check_elf_soname() and fix_elf_runpath() functions *should* not
be necessary. The result of "cd $(VER) ; make install" should be
setting the SONAME and RUNPATH correctly. If not, you should
probably be patching the sqlite3 build environment and working with
the sqlite community to get fixes back in upstream. The same can
probably be said for mapfile support.
usr/src/pkgdefs/SUNWsqlite3/Makefile
Personally, I would rather not see you generating prototype_com on
the fly via cat/find/echo
usr/src/pkgdefs/SUNWsqlite3tcl/prototype_*
usr/src/pkgdefs/SUNWsqlite3/prototype_*
You might want to sort these based on path
You might want to run Capser's fix-copyright across this workspace. The
following files need copyright updates:
usr/src/tools/install.subr
usr/src/lib/Makefile
usr/src/pkgdefs/Makefile
-Norm
Nicolas Williams wrote:
> On Mon, Feb 25, 2008 at 02:14:54PM -0800, Mike Sullivan wrote:
>
>> Nicolas Williams wrote:
>>
>>
>>> Hmmm, I don't quite buy it. SFW components are a lot more discrete than
>>> ON components. And many will install library and executable content
>>> both.
>>>
>> Like I said, that can happen in ON too - it's just that it's easier to
>> make people split their code between lib and cmd in such cases, and it's
>> not easy or friendly to have folks in sfw split that code up. But
>> it still can be a useful split, or at least useful enough it's not worth
>> changing to me.
>>
>
> I guess it can happen in ON, but I think it's unlikely -- we've taken
> major pains to avoid this for, e.g., krb5, ssh, and other things in ON
> of external procedence.
>
> But I've moved it to $SRC/lib/sqlite3, and I've generated a new webrev:
>
> http://cr.opensolaris.org/~nico/webrev-sqlite3-sfw-2nd/
>
> (which includes the tar.gz and zip archives too)
>
> BTW, my approach to reducing symbol scope for libsqlite3 causes warnings
> to be issued by ld(1) when linking with libsqlite3, so I may do without
> symbol scope reduction for now. First I'll talk to the linker folks
> though.
>
> (The warning is about having local symbols in the global symbol table.
> The warning is plainly harmless, and, IMO, shouldn't be issued _at
> all_ -- otherwise elfedit(1)ing objects loses value.
>
> Nico
>
