Add support for linking against external libsquirrel.so
Status: Inactive
Brought to you by:
dinosaur-rus
Menu
▾
▴
#3 Add support for linking against external libsquirrel.so
I am making an effort at having a nice autotools system for squirrel that would be useful for distros and provide a common method for both installing and compiling against squirrel. My effort is slightly discussed at http://squirrel-lang.org/forums/thread/3638.aspx and the results of my work are so far available at http://ohnopub.net/hg/SQUIRREL2 (and http://ohnopub.net/hg/SQUIRREL3 for squirrel-3).
I see that your project has a ``fake'' (non-autoconf) ./configure script and also that it installed a libsquirrel.so into one's system ( https://bugs.gentoo.org/314501 ). I am assuming that you have no made much modification to the squirrel API as your package installs libsquirrel.so into the system library path as if it's a convenience for other interested in using libsquirrel. So far, I see that you need libsquirrel to incorporate into its API the maxparams functionality, which means working with alberto.
Please consider trying to support linking against the libsquirrel.so that is installed by my current SQUIRREL2 setup. You should be able to get something started with:
hg clone http://ohnopub.net/hg/SQUIRREL2
cd SQUIRREL2
autoreconf -vfi
./configure
make -j
I have been able to incorporate your maxparams change into my mercurial repository for squirrel2 without any problem other than me forgetting that alberto likes CRLF ( http://ohnopublishing.net/hg/SQUIRREL2/rev/85c098bab526 ). Thus, you should be able to just use my repository, which has my autotools patch + supertux const patch (already accepted by alberto) + your maxparams patch without modification. I recommend using the pkg-config functionality from the autotools patch in your ./configure script to get the proper CPPFLAGS and LIBS variables for compiling against a system-installed squirrel.
Please do give me feedback on what I've done and give me advice on trying to push the maxparams patch to alberto. I'm willing to import commits or patches to my mercurial repository.
To be honest, I haven't tested compilation of PCRE and Squirrel as shared libraries. :)
I suggested Alberto to make the sq_setmaxparams() function part of the official Squirrel API and sent him some patches (approximately during the same period of time as pushing my patch for octal numbers upstream), but have never got his answer. So I concluded that he doesn't like this feature for some reason.
As for your patch, there's no intention of changing the build system to autotools-based one, but I'll consider adding support for the pre-installed system-wide Squirrel library.
I've updated the configuration script to support pkg-config and system-wide Squirrel library. Please try it and tell me what else should be changed to support "global" libsquirrel.
Thanks very much for your enthusiasm and willing to work with me :-).
I realized that, unfortunately, my mercurial repository did not contain enough changes for libsquirrel to even completely compile with your maxparams patch. Since squirrelsh doesn't use all of libsquirrel, it didn't make the necessary changes to sqstdlib since it didn't compile that subsection of squirrel. Well, I finally fixed my version of your patch and you should be able to see it with ``hg pull -uv''.
Here's what I noticed so far:
1. Your libsquirrel test program should have a reference to sq_setmaxparams() to ensure that the system-installed copy has your patch in it. Unfortunately, there's a chance that fagiano/alberto will never accept our request that your patch be added :-/. Thus, it'd be nice if users could see that --with-squirrel=system won't work if they're trying to compile against an unpatched version of libsquirrel at ./configure time rather than later at compile time.
2. the docs for --with-libraries assume that you'll be building a local copy of libsquirrel. If you could make it clear that that option's value only matters ``if compiling against bundled libsquirrel''.
- A related note: Having squirrelsh install libsquirrel.so makes little sense. First of all, since you don't install headers, only squirrelsh can compile against that shared library. This means that only your sqsh binary will ever be linked against libsquirrel.so and libsquirrel.so will never be shared with other binaries. Shared objects only save resources and improve efficiency when multiple binaries are linked against them. That is why I'd prefer to have supertux and squirrelsh projects link against a system-installed libsquirrel.so (and thanks again :-) ).
3. In ./configure, You refer to the C++ compiler with CPP, this makes me think of the C Preprossor, I normally see C++ compilers refered to with CXX ;-)
4. Most of your calls to pkg-config call pkg-config instead of $pkgconfig. Also, it'd be nice if ./configure respected the value of the PKG_CONFIG envvar (see /usr/share/aclocal/pkg.m4 , autoconf pkg-config support respects this var). I have worked through the stuff necessary to fix this with the to-be attached patch. There was one place where ``||'' rather than ``&&'' completely disabled calls to pkg-config, for example ;-).
Fixes ./configure script's calls to pkg-config
1. I've added a call to sq_setmaxparams() to the Squirrel test program. Messages indicating that system-wide versions of libpcre and libsquirrel are unavailable or invalid (when corresponding "--with-*=system" option is specified) were present from the very beginning of the support of their "global" versions.
2. I know that a shared library is useless when it's used by one program only. "--with-libraries" option was added as an experiment with creating shared libraries in Unix-like systems. Now I'm not even sure this feature is still necessary because I put PCRE and Squirrel code into the squirrelsh tarballs to provide a self-contained source package without external dependencies (compiler, linker, etc. are obvious exceptions :) ). And if one wants to have PCRE or Squirrel as shared libraries, one can build them from the original sources (yes, original version of Squirrel doesn't have maxparams feature, but it doesn't have out-of-the-box support of building as a shared library either :) ).
3. C++ compiler is referred as cpp_compiler and. "--with-cpp" option description also says that this option refers to the C++ compiler. Makefiles refer to the compiler as CXX. So I don't see any reason for such confusion. :)
4. This should be fixed in the Subversion repository. Please check it.
Looks good on your part, and thanks again for putting the work into updating your ./configure. Now to wait on alberto... ;-)