ports/155971: [PATCH] databases/sqlite3: always enable
EXTENSIONS
Matthias Andree
mandree at FreeBSD.org
Mon Mar 28 18:19:44 UTC 2011
Beat Gätzi:
> Wouldn't that create a conflict between sqlite3 and the new slave port? In
> this case that isn't the solution too.
> Is there a way to query sqlite3 to find out if it was build with loadable
> extensions? If yes, we could query that in the firefox port and set BROKEN
> if this isn't the case.
Indeed I'd prefer IGNORE or BROKEN, but we can't catch that so early --
and particularly not without forking processes while the Makefile is
being parsed.
The test would erroneously fail if py*-sqlite3 and/or sqlite3 is not
installed before you attempt the build, but got installed only as part
of firefox's depends - so we cannot do this earlier than post depends,
f. i. in pre-build.
There's a way that work without python (needed because python may only
be installed as firefox's dependency), and that is:
objdump -R ${LOCALBASE}/libsqlite3.so | grep -w sqlite3_load_extension
We can additionally try grepping ${PORT_DBDIR}/sqlite3/options and/or
the libfile, but again, neither is guaranteed to exist when you "make"
firefox's Makefile - and we don't want != lines.
How about the attached patch to www/firefox? It performs this check in
pre-everything (in case sqlite3 is already installed) and again in
pre-build (if it got installed in the 'make depends' stage).
As a side effect, it also removes the != line (for pthread library
extraction) as per the recent portlint warning URL, so that reading the
Makefile doesn't fork a new process.
Works for me, but please double-check.
Best
Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check-www-firefox-PGO.patch
Type: text/x-patch
Size: 5544 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-gecko/attachments/20110328/9acb6f53/check-www-firefox-PGO-0001.bin
More information about the freebsd-gecko
mailing list