|
Description
Keri Harris (RETIRED)
2005-12-23 19:29:44 UTC
Created attachment 75431 [details]
swi-prolog-5.6.0.ebuild
Created attachment 75432 [details]
swi-prolog-5.6.0-packages-mp-DESTDIR.patch
Created attachment 75433 [details]
swi-prolog-5.6.0-packages-semweb-DESTDIR.patch
Created attachment 75489 [details] swi-prolog-5.6.0.ebuild I've attached an updated ebuild to address a few issues: - additional packages now respect CFLAGS - jpl package depends on virtual/jdk - jpl package should now compile on amd64 and ppc architecture (this will fix bug #114465) - db package will build with >=sys-libs/db-4.* - xpce package depends on media-libs/jpeg - minimal use flag added to provide swi-prolog-lite functionality Created attachment 75490 [details]
swi-prolog-5.6.0-packages-CFLAGS.patch
Created attachment 75491 [details, diff]
swi-prolog-5.6.0-packages-db-db4.patch
Created attachment 75492 [details, diff]
swi-prolog-5.6.0-packages-jpl-arch.patch
Thanks for putting this together :-) Two things: 1. You mention that jpl compilation on AMD64 should work; does this mean it's intended that the whole thing yet work on AMD64? If so, it's missing an ~amd64 keyword :-) 2. I'm getting a linker error: --- make[2]: Leaving directory `/var/tmp/portage/swi-prolog-5.6.0/work/pl-5.6.0/packages/clib/maildrop/rfc2045' ../plld.sh -shared -o unix.so error.o process.o ../plld.sh -shared -o socket.so error.o socket.o nonblockio.o ../plld.sh -shared -o cgi.so error.o form.o cgi.o ../plld.sh -shared -o memfile.so error.o memfile.o ../plld.sh -shared -o files.so error.o files.o ../plld.sh -shared -o mime.so error.o mime.o maildrop/rfc2045/librfc2045.a maildrop/rfc822/librfc822.a ../plld.sh -shared -o time.so error.o time.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld: maildrop/rfc2045/librfc2045.a(rfc2045.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC maildrop/rfc2045/librfc2045.a: could not read symbols: Bad value collect2: ld returned 1 exit status x86_64-pc-linux-gnu-gcc returned code 256 *** /var/tmp/portage/swi-prolog-5.6.0/work/pl-5.6.0/src/../src/plld exit status 1 gmake[1]: *** [mime.so] Error 1 gmake[1]: *** Waiting for unfinished jobs.... gmake[1]: Leaving directory `/var/tmp/portage/swi-prolog-5.6.0/work/pl-5.6.0/packages/clib' make: *** [objects] Error 1 !!! ERROR: dev-lang/swi-prolog-5.6.0 failed. !!! Function src_compile, Line 97, Exitcode 2 !!! packages emake failed !!! If you need support, post the topmost build error, NOT this status message. --- Thanks again! --- root@mythrilspoon ~ # emerge --info Portage 2.1_pre2 (default-linux/amd64/2005.0, gcc-4.0.2, glibc-2.3.6-r1, 2.6.14-gentoo-r5 x86_64) ================================================================= System uname: 2.6.14-gentoo-r5 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.0_pre12 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O3 -g -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config /var/lib/games/*.scores /var/qmail/control" CONFIG_PROTECT_MASK="/etc/X11/app-defaults /etc/gconf /etc/gconf/schemas/ /etc/init.d/ /etc/sound/events/ /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O3 -g -pipe -fomit-frame-pointer" DISTDIR="/var/portage/distfiles" FEATURES="autoconfig distlocks nostrip sfperms strict" GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.chem.wisc.edu/gentoo/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo " LANG="en_US.utf8" LC_ALL="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/var/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="/usr/local/var/portage /home/jyrinx/var/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="amd64 X a52 aac aalib acpi4linux aim alsa apache2 audiofile avi bash-completion berkdb bitmap-fonts blas bonobo bzip2 bzlib cairo caps cdb cdda cddb cdio cdparanoia cdr crypt cscope ctype cups curl dba dbus dlloader doc dri dvd dvdr dvdread eds emboss encode esd exif expat fam fbcon ffmpeg firefox flac flash foomaticdb fortran ftp gb gd gdbm gif glitz glut gmp gnome gnuplot gpm graphviz gstreamer gtk gtk2 gtkhtml guile hal haskell icq idn imagemagick imap imlib ipv6 jack java javascript jpeg junit ladcca lcms ldap libgda libwww lzw lzw-tiff mhash ming mng motif mozilla mp3 mpeg mysql ncurses nls nptl nsplugin offensive ogg oggvorbis openal opengl pam pcre pda pdflib pear perl php pic png pnp python quicktime readline samba sdk sdl slang sockets socks5 spell ssl subversion svg tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales utf8 vorbis wmf wxwindows xine xinerama xml xml2 xosd xpm xprint xv xvid zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS (Minor update: It seems to work fine in my trusty 32-bit chroot environment on the same machine.) Created attachment 75743 [details]
a slightly cleaned up ebuild
Got to this one. So, is this a full version only, without lite?
Attached is a slightly updated ebuild - basically just the quoting and whitespace. The diff won't be telling much, so attached a full ebuild. Besides, it will be easier to use it as a base for modifications. See my next comment on some particulars..
Keri: btw, you can (and should, as soon you will have to ;)) use repoman (its part of portage) to check for all the "wrongs" that it detects. Just run "repoman scan" in the package directory..
George
Forgot to mention: it builds fine in 32bit chroot here (its amd64 system). In 64 bit mode it fails with the same error, which is due to "missing" -fPIC. Amd64 likes that option a lot and seems to handle it better than any other arch, so the easiest solution is to just force it by adding to C[XX]FLAGS, however there is opposition to it. So it is better to try to find what part of build cannot live without it and add it just there. I'll try to take a look at that at some point..
Few remarks on the package:
1. Splitting of the packages. We need to make sure full and light versions do not install any common files, unless we want to block them of course (so that user can only get either one but not both). I'll elaborate more on this in the splitting bug (#115008)..
Also, is there any need to SLOT the packages? I see this package installs binaries under lib/pl-${PV}/bin/${ARCH}, which is already good, so slotting may not need as much work, but we will have to be carefull about names for split binaries..
2. latex2html. The packages installs its own thing. Is this a standalone utility or is it used by the package itself? In the first case I think we need to decide whether we want to install it at all. Doing a quick comparison of this one and "standard" one, for which we have an ebuild, this one looks quite a bit more simplistic.. Is this actually a usefull tool or is this more of an exercise in Prolog? In the latter case I think it is just easier to drop it alltogether, in the former case we need to handle it differently.
It is a different tool and as such it is better to rename it or some such.. I can easily imagine users wanting to keep the "standard" latex2html, and blocking in not a good way to avoid intersection..
George
Yea, regarding the latex2html thing. I removed the line with tetex? from ebuild for testing on me here, as it was blocking against latex2haml that I had. We will need to add something back, when we decide how to handle the bundled latex2html.. George Created attachment 75772 [details, diff]
swi-prolog-5.6.0-packages-CFLAGS.patch
Thanks for the feedback Luke.
I don't have an x86_64 box so for this reason did not add ~amd64 to KEYWORDS. Upstream has assumed that everyone wanting to use jpl has a jdk with specific java libraries installed at $JDK_HOME/jre/lib/i386. This is not the case for amd64 and powerpc so a patch is necessary in order to specify the correct location.
Regarding the linker error, I've attached an updated packages-CFLAGS-patch that adds -fPIC to the maildrop system in the clib package. Let me know how you fare. :)
Keri.
Okay, now I'm getting this on the 64-bit side (looks like bug #114465): --- ../plld.sh -embed-shared -o libjpl.so src/c/jpl.o -ljava -lverify -ljvm /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ljava collect2: ld returned 1 exit status x86_64-pc-linux-gnu-gcc returned code 256 *** /var/tmp/portage/swi-prolog-5.6.0/work/pl-5.6.0/src/../src/plld exit status 1 gmake[1]: *** [libjpl.so] Error 1 gmake[1]: *** Waiting for unfinished jobs.... Created attachment 75775 [details, diff]
swi-prolog-5.6.0-packages-ltx2htm.patch
Hi George.
1. The only difference between the full and lite versions of swi-prolog is the extra packages provided in the packages directory of the source tarball. The compiler/interpreter is identical, so the minimal USE flag provides perhaps the easiest way of allowing the userbase to choose whether they would like to install the full or lite version.
2. The latex2html package provides some compiled libraries and prolog source libraries which are useful when handling latex from within prolog. It also provides a wrapper script to provide minimal latex2html functionality which can be safely dropped in favour of the much more mature dev-tex/latex2html. I've attached a patch to install the latex2html libraries and prolog sources in prolog's package directories. This will allow us to retain latex support in swi-prolog without it clobbering dev-tex/latex2html.
It may indeed be worthwhile looking at slotting prolog in order to allow multiple versions of the compiler and interpreter. The only files that would need to be tidied up are the links in /usr/bin and the manpages.
Created attachment 75776 [details, diff]
swi-prolog-5.6.0-packages-docs.patch
Another small patch to install documentation for the db and mp packages.
Luke, can you attach the config.log from /var/tmp/portage/swi-prolog-5.6.0/work/pl-5.6.0/packages/jpl/ I'm interested to see what your $host_cpu is being defined as. Also, can you confirm the location of libjava.so on your machine? Thanks for the fixes. I updated ebuild correspondingly - added 2 epatch'es and tested it in 32bit chroot. There was one problem though - apparently tools do not like concurrent make, I needed to pass -j1 to emake, so that line in ebuild became: emake -j1 || die "packages emake failed" With that it all compiled and installed fine. The latex2html script is not installed any more, so the ebuild seems fine on x86 at least now.. The changes to the last version of ebuild posted here are trivial (2 epatch calls and -j1 as above), but if you wish I can attach the new version as well.. George On the mad64 part:
That -fPIC change has fixed the issue and now I am hitting the java thing too.
These are some locations on my system:
# find /opt/ -iname libjava*
/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libjava.so
/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libjavaplugin_jni.so
/opt/blackdown-jdk-1.4.2.03/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
/opt/java32/lib/i386/libjava.so
/opt/java32/lib/i386/libjavaplugin_jni.so
/opt/java32/plugin/i386/mozilla/libjavaplugin_oji.so
/opt/java32/plugin/i386/netscape4/libjavaplugin.so
(there is nothing relevant in /usr/lib; java32 is sun-jdk stuff)
# java-config -L
[blackdown-jdk-1.4.2.03] "Blackdown JDK 1.4.2.03" (/etc/env.d/java/20blackdown-jdk-1.4.2.03) *
# cat /etc/env.d/java/20blackdown-jdk-1.4.2.03
[skipped headers]
VERSION="Blackdown JDK 1.4.2.03"
JAVA_HOME=/opt/blackdown-jdk-1.4.2.03
JDK_HOME=/opt/blackdown-jdk-1.4.2.03
JAVAC=${JAVA_HOME}/bin/javac
ADDPATH="${JAVA_HOME}/bin:${JAVA_HOME}/jre/bin"
ADDLDPATH="${JAVA_HOME}/jre/lib/amd64/:${JAVA_HOME}/jre/lib/amd64/native_threads/:${JAVA_HOME}/jre/lib/amd64/classic/:${JAVA_HOME}/jre/lib/amd64/server/"
MANPATH=/opt/blackdown-jdk-1.4.2.03/man
ENV_VARS="JAVA_HOME JDK_HOME JAVAC ADDPATH ADDLDPATH MANPATH"
So, looks like the easiest option is to use ${JDK_HOME} var, which should be defined when some jdk is installed (and it is in DEPEND, so that should be covered). Underneath it is jre/lib/${ARCH}..
George
Created attachment 75823 [details, diff]
swi-prolog-5.6.0-packages-jpl-arch.patch
I've attached another jpl-arch patch that should fix the amd64 compile problems. On amd64 there is no Java HotSpot client VM, so adding jre/lib/amd64/server to $LDSOFLAGS will pick up the server VM. I've also added a small fix for ppc users with blackdown-jdk-1.3.1
Updated ebuild to follow. :)
Created attachment 75825 [details]
swi-prolog-5.6.0.ebuild
Sweet - it works in 64-bit now :-) (though, as suggested above, only with MAKEOPTS=-j1) Thanks to all. Created attachment 76041 [details, diff] swi-prolog-5.6.0.ebuild.patch I've attached a diff to be applied against the ebuild attached to comment #21 in order to address a few issues: - install packages and docs only when 'minimal' is not in USE flags. - The additional packages were running make install and make check recursively in a subshell, so anything failing would not cause the emerge to fail. - make check would bail out under a variety of situations: building on any system with LC_ALL not set to a unicode friendly locale; the upstream set of tests comprise many unicode tests. They have been relaxed to accept non-unicode environments. if a prolog compiler is not already installed then the chr and xpce packages need to assert a file search path and library path within the sandbox. compiling prolog with USE="-threads" will no longer cause make check to die in the clib, semweb or ssl packages. the upstream set of checks in the ssl package include expired ssl certificates. They are now regenerated on the fly. if the xpce package is not already installed then make check would fail. Correctly setting PCEHOME within the sandbox fixes this. Patches to follow... Created attachment 76042 [details, diff]
swi-prolog-5.6.0-packages-portage.patch
Created attachment 76043 [details, diff]
swi-prolog-5.6.0-packages-jpl-arch.patch
Created attachment 76044 [details, diff]
swi-prolog-5.6.0-packages-ltx2htm.patch
Created attachment 76045 [details, diff]
swi-prolog-5.6.0-test.patch
Created attachment 76046 [details, diff]
swi-prolog-5.6.0-packages-test.patch
Created attachment 76053 [details, diff]
swi-prolog-5.6.0-packages-CFLAGS.patch
Created attachment 76054 [details, diff]
swi-prolog-5.6.0-packages-portage.patch
Created attachment 76055 [details, diff]
swi-prolog-5.6.0-packages-ltx2htm.patch
Created attachment 76388 [details, diff]
swi-prolog-5.6.0-packages-ltx2htm.patch
During src_install The prolog runtime will now generate html documents for the latex2html libraries on the fly.
Created attachment 76816 [details, diff]
swi-prolog-5.6.1-test.patch
Upstream has just released swi-prolog-5.6.1; this is a bugfix release.
The 5.6.0 ebuild can simply be renamed to swi-prolog-5.6.1.ebuild. All patches applied against swi-prolog-5.6.0 need to be revbumped to apply against 5.6.1, although swi-prolog-5.6.0-test.patch is invalidated by an updated patch I've attached in order for "make check" to successfully run the clpr scripts in 5.6.1
Created attachment 77057 [details]
swi-prolog-5.6.2.ebuild
Another upstream release containing a few important bugfixes. Rather than patch a patch, I've attached an updated ebuild. The only change to the ebuild from -5.6.1 is the addition of a new patch for threading statistics via procps.
Created attachment 77058 [details, diff]
swi-prolog-5.6.2-threads.patch
This patch ensures that if too many threads are created for virtual memory to handle, then calling thread_join will now correctly throw a resource error.
Hi Keri. Thanks for an update! Looks fine, just one really minor nitpick: /usr/lib/pl-5.6.2/man appears to be empty upon installation (as expected, since the man pages are installed where appropriate), so it can be removed in the src_install. Since there is no action on the recruiters part in that bug so far, it seems unlikely you will get cvs commit access before I go on a vacation (in two weeks now). Therefore I think I will create a new package (swi-prolog) and commit the 5.6.2 version with the relevant patches now (in a few days, if you think it is ready to go in). There has to be a wait period between the time we release swi-prolog and remove swi-prolog-lite, and this way (by releasing it before I take off for 3 weeks) we will not be loosing almost a month.. Then we can take care of clean-ups in swi-lite and eventual removal, as well as of gprolog together, when I return and you complete the process.. George Created attachment 77106 [details, diff]
swi-prolog-5.6.2.ebuild.patch
Thanks for keeping an eye on the progress of this package.
I've attached a diff of an amended ebuild to remove the redundant call to mkdir during src_install.
I think adding swi-prolog-5.6.2 to the portage tree in the next few days is a good idea. We'll sooner be able to tackle the eventual migration from swi-prolog-lite to swi-prolog, and it should also allow a larger userbase to try out the package in the meantime.
Two issues: 1. If threads is not in USE, it appears to try to compile threads anyway and bails when it can't get the pthread includes: make[2]: Leaving directory `/var/tmp/portage/swi-prolog-5.6.2/work/pl-5.6.2/packages/clib/maildrop/rfc822' ../plld.sh -ggdb3 -O1 -O2 -O3 -pipe -march=athlon-xp -mmmx -msse -m3dnow -fno-strict-aliasing -Wall -fpic -I. -Imaildrop/rfc2045 -Imaildrop/rfc822 -DHAVE_CONFIG_H -c -o time.o time.c time.c:236: error: `PTHREAD_MUTEX_INITIALIZER' undeclared here (not in a function) time.c:237: error: `PTHREAD_COND_INITIALIZER' undeclared here (not in a function) Workaround: add threads to USE. 2. It seems to have problems with parallel make: i686-pc-linux-gnu-gcc -c -ggdb3 -O1 -O2 -O3 -pipe -march=athlon-xp -mmmx -msse -m3dnow -fno-strict-aliasing -Wall -fPIC -DHAVE_CONFIG_H -I/var/tmp/portage/swi-prolog-5.6.2/work/pl-5.6.2/include -I../../src -I../../src -DSWI -DHAVE_CONFIG_H -I/usr/include -I/usr/include -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include pcecall.c -o ../../src/pl/pcecall.o gmake[3]: *** No rule to make target `../../src/libXPCE.a', needed by `../../src/pl2xpce.so'. Stop. gmake[3]: *** Waiting for unfinished jobs.... gmake[3]: Leaving directory `/var/tmp/portage/swi-prolog-5.6.2/work/pl-5.6.2/packages/xpce/pl/src' gmake[2]: *** [pl-itf] Error 2 Workaround: MAKEOPTS="-j1". Thanks! Created attachment 77506 [details, diff]
swi-prolog-5.6.2-threads.patch
Thanks for the bug report Ed!
Find attached an updated threads patch that will also ensure the time module of CLIB uses a shared table only if threading is enabled.
Created attachment 77509 [details, diff] swi-prolog-5.6.2.ebuild.patch This patch obsoletes the ebuild patch in comment #37. It now ensures that the swi packages are not parallelized in make. you should really be submitting this patches upstream rather than here ... they do releases quite often so we could just get the patches incorporated and then add an ebuild for the next version although the `make -C` change prob wont be accepted as it isnt portable SpanKY, pl-5.6.3 will be released in the next day or so. I've already had fixes for the threading resource exception handling, single threading tables and the occurs check committed. The DESTDIR fixes are for deprecated packages so won't be committed. On another note, pl-5.7.x is also in the works; it will contain improved Java Hotspot support so arch fixes have already been tagged for that. (I work for a company that does upstream development so appropriate patches for Gentoo also get tagged for future releases :) Created attachment 77625 [details]
swi-prolog-5.6.3.ebuild
well if the packages are deprecated we might as well disable them in the ebuild :) Created attachment 79824 [details]
swi-prolog-5.6.4.ebuild
Another upstream release. :) This release incorporates fast prefix searches in the RDF-DB package, and byte counts in stream positions. Many of the issues addressed by the patches against -5.6.3 have been incorporated in -5.6.4 (unicode awareness in make check, DESTDIR fixes, x86_64 jpl checks etc).
-5.6.4 patches to follow
Created attachment 79825 [details, diff]
swi-prolog-5.6.4-CFLAGS.patch
Created attachment 79826 [details, diff]
swi-prolog-5.6.4-gmp.patch
Created attachment 79827 [details, diff]
swi-prolog-5.6.4-test.patch
Created attachment 79828 [details, diff]
swi-prolog-5.6.4-packages-portage.patch
Created attachment 79829 [details, diff]
swi-prolog-5.6.4-packages-cppproxy.patch
Created attachment 79830 [details, diff]
swi-prolog-5.6.4-packages-db-db4.patch
Created attachment 79831 [details, diff]
swi-prolog-5.6.4-packages-jpl-arch.patch
Created attachment 79832 [details, diff]
swi-prolog-5.6.4-packages-ltx2htm.patch
Created attachment 79833 [details, diff]
swi-prolog-5.6.4-packages-test.patch
i thought you were becoming a dev so you could do this stuff yourself ? i was worried at first you wouldnt be able to handle swi-prolog, but it's pretty clear now that you know a hell of a lot more than i about it Yep, I'm becoming a dev (watch this space); then I'll be able to commit straight to cvs. Until then this bug will have to suffer the endless stream of swi-prolog ebuilds and patches. :) Created attachment 79986 [details, diff]
swi-prolog-5.6.5.ebuild.diff
swi-prolog-5.6.5 has just been released. It contains a few bug fixes (rdiv functions, GC and AVL library(assoc)). The gmp fixes mean that the mp package is now superfluous and contributes nothing to the build. It also contains new ssl certificates so we now longer have to generate them on the fly for make test.
Find attached a diff against swi-prolog-5.6.4.ebuild. The 5.6.4 patches will apply against pl-5.6.5 with the exception of the CFLAGS patch and packages-test.patch
Created attachment 79987 [details, diff]
swi-prolog-5.6.5-CFLAGS.patch
Created attachment 79989 [details, diff]
swi-prolog-5.6.5-packages-test.patch
Created attachment 80143 [details, diff]
swi-prolog-5.6.5-packages-jpl-arch.patch
I've attached an update to the jpl patch that will provide Java Hotspot support for both the ibm and older blackdown jdks for powerpc.
swi-prolog-5.6.6 has been released. It contains two new http libraries and bugfixes in prolog_exception_hook/4 and stack limits for cyclic terms. Renaming the -5.6.5 ebuild and patches to -5.6.6 is all that is required for this release. Created attachment 81743 [details, diff]
swi-prolog-5.6.7.ebuild.patch
5.6.7 has just been released which fixes a few issues with rational numbers and the formatting of atoms. It also now correctly refers to CLP(Q) (with multithreading) in it's contraints logic programming package. The semweb package contains a _big_ change to its support of literals.
Find attached a patch to be applied against the -5.6.6 ebuild. As prompted in an email from george, the patches have dropped reference to the version of the swi-prolog package in order to reduce the renaming of unchanged patches.
Created attachment 81744 [details, diff]
swi-prolog-CFLAGS.patch
Updated CFLAGS patch to handle a change in the Semantic Web library.
Created attachment 81745 [details, diff]
swi-prolog-packages-cppproxy.patch
CLP(Q,R) update.
Created attachment 81746 [details, diff]
swi-prolog-packages-test.patch
Include a literal map test in the semweb package.
Ok, looks good. Seems to build and run fine (although I was not sure how to do an extensive test, as I am not much into prolog, but it started and accepted some random input without crashing :)). Lets try to wait for the resolution of #117467 so that we can commit this together, however if it takes another month for recruiters to set you up I guess I'll have to commit this one myself in a week or two (so that we do not have to wait as long before picking up with masking swi-prolog-lite and other stuff..) George Closing; swi-prolog-5.6.8 has been committed to cvs. |