[bug#48463] gnu: Add j.

[Leo Prikler <leo.prikler@student.tugraz.at>]

Hi elaexuotee,

Am Sonntag, den 16.05.2021, 19:54 +0900 schrieb elaexuotee@wilsonb.com:
> Hey Guix,
> 
> This packages up the J programming lanuage. The build scripts that
> upstream provides are pretty hostile to package maintainers, so we
> have to jump through quite a few hoops to get the build working.
Yup, that much is visible from the package description.

> I have had this in my personal, private channel for a while, tweaking
> it over time, so I believe it works fairly well in practice. Here are
> the high-level design decisions I have made:
> 
> 1) Provide multiple J versions;
> 
> It is extremely common for J users to have multiple versions
> installed in parallel since there are often major, breaking changes
> between (non-patch-level) releases.
> 
> In addition, a very large fraction of J users keep the beta installed
> as well, so I have elected to provide this too.
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.

> 2) Bundle together all variants of the interpreter along with a
> wrapper script that selects the most featureful one at runtime;
> 
> There are 3 versions of the interpreter, supporting different CPU
> feature-sets: vanilla, AVX, AVX2. This package elects to build all
> these variants and provides a wrapper script that launches the "most
> AVX-y" version possible at runtime.
> 
> Essentially, this is trying to make up for upstream's lack of a fat
> binary.
Are fat binaries the accepted HPC way?  I'm not up-to-date to this.

> 3) Try to mirror the FHS standard for installation locations;
> 
> For the most part, J uses idiosyncratic defaults for where it looks
> for library files and the like. This package elects to configure
> things so files sit in more standard locations---e.g. runtime scripts
> sit under .../share/j; configuration files sit under .../etc/j; etc.
> 
> 4) Point the J package manager to $HOME/.j/<version>.
> 
> J maintains its own mini package repository for "addons", which are
> simply officially-supported J scripts. This package sets things up so
> that these packages get installed to .j/<version>/addons. In
> addition, other related directories are gathered under .j/<version>.
Those should be fine.

> Items on the TODO list:
> 
> 1) Write an importer and create packages for J addons;
> 
> This is currently in progress.
> 
> 2) Create a something like a jsoftware-union procedure to bundle up J
> with user-selectable addons;
> 
> This is necessary since the interpreter looks for addons at a
> specified path. We probably want to mimick something like texlive and
> provide both an "all batteries included" package along with one where
> users can select which addons they want.
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?

> 3) Support more older versions of J.
> 
> J is open source starting with j801, so it'd be nice to have packages
> for the entire j80x series too. Unfortunately, those use an entirely
> different set of build scripts from the current j90x series, so it
> will require munging-work similar to what we already have.
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.

> +(define-record-type* <jlib-build-configuration>
> +  jlib-build-configuration make-jlib-build-configuration
> +  jlib-build-configuration?
> +  (builder      jlib-build-configuration-builder (default
> "guix.gnu.org"))
> +  (version      jlib-build-configuration-version (default #f))
> +  (revision     jlib-build-configuration-revision (default #f))
> +  (hash         jlib-build-configuration-hash (default #f))
> +  (type         jlib-build-configuration-type (default 'release))
> +  (patches      jlib-build-configuration-patches (default '()))
> +  (extra-inputs jlib-build-configuration-extra-inputs (default '()))
> +  (extra-envars jlib-build-configuration-extra-envars (default
> '())))
> +
> +(define make-jlib
> +  (match-lambda
> +    (($ <jlib-build-configuration>
> +        builder jversion revision hash type patches extra-inputs
> extra-envars)
Please try to use keyword arguments.

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

Regards,
Leo