On Thu, May 04, 2023 at 12:46:15AM +0200, Ralf Hemmecke wrote:
> > > Then maybe we do that with HashTable afterwards. I would rather like
> > > this hunchentoot thing inside FRICASsys as I described here
> > >
> > > https://hemmecke.github.io/fricas/install.html#jfricas-optional
> > >
> > > patches are in the wip/fricas-jfricas branch of my github repo.
> >
> > Hmm, in one place you mention wip/fricas-sbcl-hunchentoot, which one
> > should I look at.aaOoop...
>
> I say
>
> git clone -b wip/fricas-sbcl-hunchentoot
> https://github.com/hemmecke/fricas.git
>
> on the above URL (install.html), then it is certainly that.
> I locally work on wip/fricas-jfricas but never pushed that back to
> github. Anyway wip/fricas-sbcl-hunchentoot is the one.
>
> > > The above basically describes a way to build everything from the
> > > gitrepo that could then make a distribution.
>
> > Well, quicklisp dependence is very problematic. One trouble is that
> > during release build there is no network access.
>
> OK, but you must somehow get all fricas prerequisites onto that machine.
> I experimented with Kurt and using quicklisp was the easiest to get
> hunchentoot into a loadable situation without juggling too much with a
> lot of problems.
>
> 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.
> 2) build a distribution as a release manager
>
> I was not aware that you insist on "no network" during release build
> (but actually, at the time you are able to start "configure && make" no
> network is concacted).
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.
If you want reasons:
- security of build infrastructure: with explicit list of sources
trust is explicit (easy to inspect what is trusted) and limited.
With fetching during build trust is distibuted and hard to inspect.
- reproduciblity and verification: package descriptions contain
cryptographic checksums, so there is warranty that for given
package version the sources will stay constant
- people in many part of world have intermitent net access, they
can fetch sources, but only at some times/places
> > Another trouble is hardcoded paths. FriCAS is supposed to find all
> > files that it needs relative to path specified by FRICAS environment
> > variable. Currently for Lisp files I use simple approach:
> > everything that is needed is loaded and dumped as part of core.
>
> If you saw some paths on the above URL, then they are deliberately done
> through environment variables. Nothing is hardcoded. I just used FDIR as a
> common place to do all the work. When that directory is remove, nothing else
> on your computer would be change. (That was done for users that want to
> install themselves, but is actually also interesting for building a
> distribution.
>
> The other thing is, once FRICASsys is built, and put into the binary release
> tarball, then the target system (end user) does not have to have quicklisp
> or hunchentoot, because hunchentoot is inside the FRICASsys image. That's
> the whole idea -- hunchentoot into the image. There is then also no need to
> fiddle around with SBCL_HOME.
OK, I will how this works.
> I'm a bit busy with other things, but will try to open a pull request on
> github so that we can discus further on the PR and hopefully Kurt will then
> also chime in and comment.
You gave me above branch to fetch, that is enough for me, pull request
does not make it easier (at least for me).
--
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/20230504003630.tuhijylmhzp2ppmb%40fricas.math.uni.wroc.pl.
