On Sun, Aug 18, 2002 at 04:57:56PM +0200, Federico Mennite scribbled:
> Hi,
> I'm actually partecipating in the development of an IRC bot formely know
> as eggdrop.
> In the development branch the support for javascript, as funtionality
> extension, has been added.
> Recently we noticed that our configure script failed to correctly detect
> spidermonkey on debian systems because of the renaming from libjs to
> libsmjs.
> By reading the package's changelog I learned that the renaming is dued
> to another javascript implementation named njs.
>
> Wouldn't it have been better to have have the njs and the spidermonkey
> package conflicting instead of the renaming?
> I understand that njs and spidermonkey don't have any other reason to
> conflict besides the library name.
> I also understand the they have totally different APIs.
Yes, and it's yet another reason not to conflict. I see no reason at all not
to allow applications using either spidermonkey or njs to coexist on a
single system. In fact, it would be a broken approach to create such kind of
a conflict. Since njs existed earlier, I have renamed the spidermonkey to
that name. The alternative was to invent a soname scheme for spidermonkey -
which can be even less desirable than merely changing its name.
> Is the renaming somewhat official or known to the upstream authors? I
No, there's no reason to bother them with it, I guess.
> mean, what if every vendor starts renaming libraries? ;)
Well, what is your suggestion in this case (short of conflicting with njs)?
> Initially someone suggested me to add smjs to the list of serached
> javascript libraries. The solution is quite straight forward, but
> thinking about the future I was a bit concerned.
How come? In the development version of Caudium I have chosen to let the
person compiling the webserver to choose a prefix to the js library (Caudium
in the CVS contains spidermonkey support) - and that's what the Debian
package for Caudium uses. I can assure you that the name will not change on
the Debian system (unless there's a different way to not cause the name
clash with njs, of course) so there are no worries about the future. FYI,
Caudium contains two glues - one for njs and the other for spidermonkey...
> It might become difficult to detect the correct headers matching a
> certain library especially if you think about different versions of the
> same library.
Hmm, I see no reason to keep different versions of the development files for
the same library on the system. If you are concerned about the binary
compatibility, I guess that the way to go (unless the upstream decide to
start using sonames) will be to add a "version" number to the library name
on Debian (i.e. *smjs1, *smjs2 etc.)
> If you ever tried to detect matching tcl libraries and headers of older
> tcl versions with autoconf it might be clearer of what i'm talking about.
AC_ARG_WITH(smlib,
AC_HELP_STRING([--with-smlib],[Compile with the specified SpiderMonkey
library name (without the 'lib' prefix, defaults to 'js')]),
caudium_cv_smlib=$withval,
caudium_cv_smlib=js)
AC_CHECK_PROGS(perl, perl perl5, x)
if test x$perl != xx ; then
PERL_LDFLAGS=$perl -MExtUtils::Embed -e ldopts
else
PERL_LDFLAGS=""
fi
AC_CHECK_LIB(m, cos)
AC_CHECK_LIB(crypt, crypt)
AC_CHECK_LIB(dl, dlopen)
dnl this is required if SpiderMonkey is compiled in the thread safe mode
AC_CHECK_LIB(nspr4, PR_Malloc)
dnl SpiderMonkey _may_ be compiled with Perl support
AC_CHECK_LIB(perl, PL_gid)
OLD_LIBS="$LIBS"
LIBS="$PERL_LDFLAGS $LIBS"
SM_LIBS=""
AC_CHECK_LIB($caudium_cv_smlib, JS_NewContext,
AC_DEFINE(HAVE_LIB_SMJS, 1, [Define if you have the SpiderMonkey library
installed])
SM_LIBS="$SM_LIBS -l$caudium_cv_smlib $PERL_LDFLAGS"
)
LIBS="$OLD_LIBS"
dnl try to find the jsapi.h file
SM_CFLAGS="-DXP_UNIX"
AC_MSG_CHECKING([the SpiderMonkey CFLAGS])
for d in $prefix/include/$caudium_cv_smlib $prefix/include ; do
if test -f $d/jsapi.h ; then
SM_CFLAGS="$SM_CFLAGS -I$d"
break
fi
done
AC_MSG_RESULT([$SM_CFLAGS])
AC_SUBST(SM_CFLAGS)
AC_SUBST(SM_LIBS)
The above is cut-n-pasted straight from the caudium configure.ac file. As
you can see, it's pretty straightforward.
> These may seem weak points given that autoconf gives enough flexibily to
> test everything. I just want to know your point of view and eventually
> avoid a tcl-like configure hell :)
There will be no hell. The current situation is, IMO, the cleanest possible
solution for now. If I started using own soname scheme, then in the future
there might be a clash with the upstream should they start using it. Right
now, the difference is minimal.
regards,
marek
Attachment:
pgpih51tDboEb.pgp
Description: PGP signature