[bug#48463] gnu: Add j.

[elaexuotee]

Thanks for taking a look!

Leo Prikler <leo.prikler@student.tugraz.at> wrote:
> That should be fine, we provide multiple versions for other packages
> where applicable as well.  Do note, that we should try to keep the
> number limited, though.  You may perhaps want to export make-jlib, so
> that the user can build their own.

Cool. I like the idea of exporting the build procedures.

> Are fat binaries the accepted HPC way?  I'm not up-to-date to this.

I believe so? Don't quote me on that though. For this particular package the
overhoad is just ~8MB, so I don't think it's much of an issue either way. It
would probably be more of a hassle to split j into a package for each variant.

> Both sound like good ideas, although I'm a little less sure about the
> texlive one.  Would a meta-package like gnome also be acceptable?

A metapackage is certainly practical. The entire set of J addons currently
weighs in at a whopping 50MB. hehe. However, there are about 125 addons in
total, so it simply feels "more correct" to let the user also choose just the
addons they want, which I think would require something like jsoftware-union.

That said, either way, an "all batteries include" package would be good to
have, and since this is way easier than packaging the addons separately, I'll
definitely work on the metapackage first.

> As above, I'd prefer if it was one procedure and one package pointing
> to the latest j80x, assuming all of our added patches can also be
> applied to earlier versions.

Yeah, that would definitely be ideal.

Unfortunately, it's not so straigthforward. The the "major versions" are the
xxx part of jxxx-y, with large changes between each, e.g. j902 introduced and
non-compatible API change over j901. So, from a pure J user perspective, having
all jxxx versions available is ideal.

However, each version seems to require its own set of build flags and sometimes
version-specific patches (like in the j901 case). We probably don't want to
push those settings out into user manifest specs.

On the other hand, there are already 10 versions from j801 to j903.

> > +(define make-jlib
> > +  (match-lambda
> > +    (($ <jlib-build-configuration>
> > +        builder jversion revision hash type patches extra-inputs
> > extra-envars)
> Please try to use keyword arguments.

Actually, maybe these "build configuration" records could solve the above
"too many versions" problem. We could offer only the latest J (and J beta?)
packages in the repo, but let (gnu packages jsoftware) export a set of "default
configurations" for old versions to be used with the make-j procedure.

Any particular reason to avoid using records though? Currently, its letting us
share configuration options between j902 and j903 that don't work in j901.
Personally, I thought this felt like a nice declarative, scheme-y way to go,
but my Scheme is still very amateurish. Definitely wanting to rectify any
strange ideas I may have.

> > +       (properties `((jversion . ,jversion)
> > +                     (jrevision . ,revision)
> > +                     (jtype . ,type)))
> Are those used anywhere?  Can jversion and jrevision not be parsed from
> (package-version jlib)?

The make-j procedure uses them. We'd have to parse out these from both the
version string and package name with a what's essentially the inverse of the
jname procedure. I found it a lot more readable and less hassle to just
propagate this data directly.

However, if there's a particular reason why using properties is problematic,
I'll try to see what I can do.