scilab-bin: init at 5.5.2

[khumba]

How does Nixpkgs feel about binary packages? Here's a derivation for the binary version of Scilab 5.5.2. A built-from-source Scilab 5 package looks to be a lot more work, and some dependencies are missing from Nixpkgs, but the binary version with bundled dependencies works.

I've been using this on x86_64 with this commit applied on top of my current nix-channel commit (bb79e19) with only a trivial change (stdenv.gcc.gcc became stdenv.cc.cc on master), and have had no problems with Scilab. I haven't tested on 32-bit. I tried to build on top of master, but got this error. Is this a problem with the package, or a problem with mixing master and stable?

~/nix/nixpkgs.git $ nix-build . -A scilab-bin
these derivations will be built:
  /nix/store/mm7r1bm6lhjwr03rrvpsljgrsdkhljk0-scilab-bin-5.5.2.drv
building path(s) ‘/nix/store/0lkjr88x086vb180xw0bzmbwc7cg32sr-scilab-bin-5.5.2’
unpacking sources
unpacking source archive /nix/store/1a5sn050100ndgqzyda9snrcpl7nynzg-scilab-5.5.2.bin.linux-x86_64.tar.gz
source root is scilab-5.5.2
post-installation fixup
cat: /nix-support/dynamic-linker: No such file or directory
stat: No such file or directory
builder for ‘/nix/store/mm7r1bm6lhjwr03rrvpsljgrsdkhljk0-scilab-bin-5.5.2.drv’ failed with exit code 1
error: build of ‘/nix/store/mm7r1bm6lhjwr03rrvpsljgrsdkhljk0-scilab-bin-5.5.2.drv’ failed

Thanks!

[khumba]

I missed that $NIX_GCC became $NIX_CC as well. Fixed and tested against master.

[lucabrunox]

It looks like you have done a lot more work to make the binary work than copy pasting the existing 4.x derivation. Better ship the source compilation anyway.

[khumba]

Scilab 5 is a major upgrade from Scilab 4, and it uses Java much more heavily, particularly for the GUI. There are a number of Java dependencies that are missing and I don't have time to add them all to the tree: Flexdock, JOGL, Scirenderer, Jrosetta, Jhall, JLaTeXMath, jgraphx, jeuclid-core, batik >=1.7, xmlgraphics-commons [1]. I agree it would be much better to have a source build though.

[1] http://wiki.scilab.org/Dependencies%20of%20Scilab%205.X

[lucabrunox]

It's ok for me, the fact that it's called scilab-bin should be quite clear it's not built by nix.

[khumba]

On Wed, 02 Sep 2015 08:17:52 -0700
lethalman notifications@github.com wrote:

It's ok for me, the fact that it's called scilab-bin should be
quite clear it's not built by nix.

Alright :). It's possibly that less heavy-handed patching of the
shared objects would suffice -- might not need to patch them all --
but I'm not sure I know how to test all of them manually.

Also, if the jdk expression exports a classpath variable so that I
don't have to list the lib/openjdk/... paths manually, please let me
know! I didn't see one.

Thanks.

[khumba]

On Wed, 2 Sep 2015 08:39:14 -0700
Bryan Gardiner bog@khumba.net wrote:

Also, if the jdk expression exports a classpath variable so that I
don't have to list the lib/openjdk/... paths manually, please let me
know! I didn't see one.

s/classpath/.so-path/

[lucabrunox]

@khumba jdk.home

[khumba]

Okay, thanks, reworking...

[khumba]

Okay, Scilab even bundles a JVM, so for simplicity I'm leaving it to its own devices there. Here's the new version, please take a look, thanks!

[khumba]

Despite Scilab running okay for everything I've needed and even doing things like running TCL without having it being told Nix's version is, ldd says that there are a bunch of bundled .so's with dependencies not found (things that aren't on buildInputs, lapack etc.). I'll patch these too. <WIP>

[vcunat]

Still WIP?

[rasendubi]

(triage) We still don't have scilab-5 and no update here. Should this be closed? merged as is?

[khumba]

Rebased. This can be merged as is. It works as far as I can tell (graphing, installing packages from ATOMS, Xcos, help pages).

[teh]

While I understand the pain of figuring out build rules for nix and therefore going the binary-route I'm a bit worried about the proliferation of pre-compiled downloads in nixpkgs, especially for Java (as is the case here).

What do you think about adding an additional field to meta to mark binary-download packages? Then we could keep some stats?

[vcunat]

I think they're rather rare, except for SW that doesn't provide sources at all and much of java stuff (that provides portable binaries).