Re: [Xsb-development] xsb Debian package available for testing

[Luis F. P. de C. <lu...@cs...>]

Hi Kristis,

Kristis Makris <kri...@as...> writes:

> Hello,
> 
> After syncing up with the 2002-05-09 snapshot out of CVS, I have what
> seems to be a (very beta,) somehow functional xsb package for Debian
> posted on:
> 
> http://www.public.asu.edu/~makrists/debian/xsb/xsb_2.4.20020509-1_i386.deb
> 
> Hopefully, I'll setup a proper apt-able area soon.
> 
It's really looking good. You're doing a terrific job.

> There are a few more files in the package that I could get rid of. I'd
> encourage testing (Luis??); any feedback is very welcome, even the most
> trivial. 

Ok, I've found one problem, which I guess is mostly because of our
script that finds XSB. You seem to have compiled on an i586, and the
/usr/bin/xsb script makes a runtime test to look for the right
processor (i686 in my case), and thus fails for me. 

> I've (so far) compiled with no support for ODBC, Oracle, libwww or
> the tk XMC GUI, but I'm now having more time in my hands to become
> ambitious. It looks like I could use ~xsbtests and the examples for
> verifying some of these features as I compile them in.
> 
> I still believe that xsb should be split up in multiple packages. It
> makes no sense to have xsb depend on emacs (a 10MB download) simply
> because the flora mode gets installed. There should be a separate xsb-el
> package to provide just that. Similarly, it's counter-intuitive to have
> xsb depend on tk, when the tk GUI is not provided (yet) or may not be
> wanted by a user. I'd like to isolate the packages that can be compiled
> without any dependencies on XSB and make a "recommended" xsb-utils (or
> xsb-extra) package. And I still believe there xsb-doc should also be
> separate.
> 
I completely agree with you. Of course, that'll probably make your
life harder. ;)

> Some things I've noticed during my latest build (just an FYI) are below.
> I'm guessing some build failures are a side effect of me picking a
> random snapshot.
> 
> 1)
> 
> gcc -I/home/mcmicro/debian/xsb-2.4.20020509/config/i586-pc-linux-gnu  -c
> -O4 -fomit-frame-pointer -finline-functions -Winline -Wall  emuloop.c
> emuloop.c: In function `emuloop':
> emuloop.c:332: warning: variable `flag' might be clobbered by `longjmp'
> or `vfork'
>         emuloop.c:1778: warning: control reaches end of non-void
> function
> 
Ok, the first one is well-known, and it's really gcc being too
conservative. The second one should be easy to fix, I'll take a look.

> 
> 2) Please apply the attached patch for a fix to this:
> 
> checking whether we are using SunPro C... no
> ./configure: configure: command not found
> 
Ok, I'll do it.

> 3) Is the plan to distribute the tex files used to make up both the xsb
> and flora2 documentation or distribute the .ps/.pdf files generated? In
> either case ~XSB/admin/TarRelease.sh (and probably the other release
> scripts) will need to be modified to be consistent with this scheme.
> Currently, the manual{1,2}.ps files are built-up and distributed, while
> flora comes in tex format. TarRelease.sh is the file I call and count as
> my baseline for "new releases", even though those are currently random
> CVS snapshots.
> 
I guess we could distribute the .ps and/or .pdf only.
> 
> 4) 
> | ?- [Compiling asmpass2]
> [Preprocessing asmpass2.P]
> ++Error[XSB]: [Compiler] While preprocessing asmpass2.P. Compilation
> aborted.
> 
> XSB exited with exit code: 1
> make[3]: *** [all] Error 1
> make[3]: Leaving directory
> `/home/mcmicro/debian/xsb-2.4.20020509/cmplib'
> make[2]: *** [cmplib] Error 2
> make[2]: Leaving directory `/home/mcmicro/debian/xsb-2.4.20020509'
> make[1]: *** [remake_dot_O_files] Error 2
> make[1]: Leaving directory `/home/mcmicro/debian/xsb-2.4.20020509/build'
> 
This is just compiling the system you just got from CVS? I'll try to
reproduce it, but this seems new.
> 
> 
> 5)
> | ?- [Compiling
> /home/mcmicro/debian/xsb-2.4.20020509/debian/tmp/2.5/packages/wildmatch]
> [Module wildmatch compiled, cpu time used: 0.0700 seconds]
> [wildmatch loaded]
> [Compiling
> /home/mcmicro/debian/xsb-2.4.20020509/debian/tmp/2.5/packages/wildmatch/wldmtchconfig]
> [Preprocessing
> /home/mcmicro/debian/xsb-2.4.20020509/debian/tmp/2.5/packages/wildmatch/wldmtchconfig.P]
> [wldmtchconfig compiled, cpu time used: 0.2010 seconds]
> [wldmtchconfig loaded]
> ++Error[XSB]: [Runtime/P] Module  foreign  is not found in XSB library
> directories
> Aborting...
> | ?- [Compiling
> /home/mcmicro/debian/xsb-2.4.20020509/debian/tmp/2.5/packages/regmatch]
> [Module regmatch compiled, cpu time used: 0.0690 seconds]
> [regmatch loaded]
> [Compiling
> /home/mcmicro/debian/xsb-2.4.20020509/debian/tmp/2.5/packages/regmatch/regmtchconfig]
> [Preprocessing
> /home/mcmicro/debian/xsb-2.4.20020509/debian/tmp/2.5/packages/regmatch/regmtchconfig.P]
> [regmtchconfig compiled, cpu time used: 0.1600 seconds]
> [regmtchconfig loaded]
> ++Error[XSB]: [Runtime/P] Module  foreign  is not found in XSB library
> directories
> Aborting...
> | ?- [Compiling
> /home/mcmicro/debian/xsb-2.4.20020509/debian/tmp/2.5/packages/slx]
> [slx compiled, cpu time used: 0.0090 seconds]
> [slx loaded]
> [Compiling
> /home/mcmicro/debian/xsb-2.4.20020509/debian/tmp/2.5/packages/slx/slxshell]
> [slxshell compiled, cpu time used: 1.0090 seconds]
> [slxshell loaded]
> 
> 
To be true, I could never make regmatch work in my Debian machines
(not that I tried that much, anyway). 
> 
> 6)
> 
> Copying packages...
> cp: cannot stat `/home/mcmicro/debian/xsb-2.4.20020509/packages/*.xwam':
> No such file or directory
> 
> 
> 7) There is a big list of files I'm manually removing from the area make
> install copies into the *xsb release* files. It's mainly READMEs, TODOs,
> Makefiles, and tex .log/.bib/etc. files that don't belong there; I can
> send over the list. I'd prefer you folks cleaned up the install rule,
> rather than me. Also, must ALL the .P and .H files be installed through
> the install rule ? Or is the presense of some .O/.xwams enough is some
> cases?
> 
If you want to send the list of files to me, I'll take a look into it.

> 8) After wrestling and maintaining incremental changes to the debian
> build process files for 4 months now, I've become a little more
> interested in taking Luis up on his offer of me being provided some area
> within the repository to commit all files debian related. Perhaps a
> toplevel ~dist/debian directory within CVS, or something to that effect?
> This should allow for people to package xsb for other distributions
> while still maintaining some structure within the repository for
> packaging-work files. I don't know how granular the CVS permissions can
> be setup within Sourceforge so I'm only given minimal permissions to a
> "dist" module; I hope that's doable. I could send over files manually to
> Luis for commiting if that's preferred, even though it would be an
> inconvinience.
> 
I'll take a look and try to find a suitable way for us to do this.

-Luis