On Sat, Jun 10, 2023 at 11:40:58PM +0200, Ralf Hemmecke wrote: > > > There are two problems to solve. > > > > > > 1) easily build from github sources (getting prerequisites on the fly) > > > for end users that build fricas themselves > > > > If the user wants quicklisp I have nothing againt it as a possiblity. > > OTOH I would like users to be able to fetch, disconnect and build. > > Another thing is ability to recreate old versions. > > I have seen (but not yet tested) your hsbcl stuff. > > http://www.math.uni.wroc.pl/~hebisch/fricas/hsbcl.tar > > What I like is that you basically give explicit version numbers in the parts > that are necessary to build hunchentoot. Yes, I support the idea of having > concrete version numbers. > > Where I would be not so happy about is to put those zip (or source files) > into the fricas repository.
Yes, I do not plan to put "zips" into repository. > I would accept to put it into the distribution > tarball, but that is only half of the story. A user should also be able to > build from the git sources. So it would be good to have a script that can be > run before "configure" in order to get those additional prerequisites. Well, ATM hsbcl.tar tarball consists to build script + files that quicklisp would fetch. We can put hsbcl.tar in our distribution area (together with other tarbals) or we could put list of dependencies in INSTALL. I think that conceptually hunchentoot is not different than gmp: if it is installed and we use matching lisp, then we can use it. But it is up to user/packager to make sure that dependencies are available. Of course, there is question of convenience: long list of dependencies may discourage most of users. So the tarball and build script. One could try to integrate creation of 'hsbcl' into our build system. But after thinking a bit about this I am not sure if this is necessary. Namely, as long as dependencies are not part of source tree there will be extra step or two. IMO few extra manual steps are not big hasle. OTOH extra steps means more flexibility to users. Some users may prefer quicklisp. Distribution packagers presumably have their own ways and more automation on our side may interfere with their work. > Since jfricas is currently restricted to sbcl and FriCAS can be considered a > something on top of quite a variety of lisps, I am actually not even sure > whether it is right to put the hunchtoot stuff into a source distribution. > In the binary (on top of sbcl) distribution, it would certainly make sense. If we distribute binary containg hunchentoot, it make sense to provide sources used to build it. One possibility is to put hunchentoot with dependencies into "fat" distribution tarball. Probably better way is to provide separate tarball with hunchentoot and dependencies. > > > 2) build a distribution as a release manager > > > I am not sure what is current practice of Linux distributions, but > > past standard was that all files were fetched by distribution > > infrastructure. Network access during build was forbidden. So > > "no network" during build was/is important for compatibility > > with packaging FriCAS for Linux distributions. > > I have no problem with the no-network-paradigm. The only question is how to > tell the user (via documentation or via a little script) how to get the > prerequisites if "configure --enable-webspad" (i.e. jfricas) is wished. A > user would anyway have to install jupyter himself. Something like I wrote (where xxxx is link to repository): wget xxxx/hsbcl-1.3.9.tar tar -xf hsbcl-1.3.9.tar hsbcl-1.3.9/build_hsbcl And then appropriate --with-lisp > > To try: > > > > wgethttp://www.math.uni.wroc.pl/~hebisch/fricas/hsbcl.tar > > tar -xf hsbcl.tar > > cd hsbcl > > time ./build_hsbcl > rap1 2>&1 > > > > this creates executable called 'hsbcl' which can be used to > > build FriCAS. > > I've build fricas with hsbcl and no quicklisp and installed jfricas on top > of this. The whole thing works with hsbcl and the current master. > No additional patches from my side are required. In other words, if a user > provides a version of SBCL that lets webspad start hunchentoot > > https://github.com/fricas/jfricas/blob/master/jfricas/webspad.lisp#L217 > > then jfricas can be installed roughly as described at > https://hemmecke.github.io/fricas/install.html#jfricas-optional > The part with quicklisp and hunchentoot installation can be skipped. Good to know. -- Waldek Hebisch -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20230611004214.l4opbapckslb3f67%40fricas.math.uni.wroc.pl.
