#3018 scilab-4.1.2-1000

[Jack Howarth]

Update package to latest 4.1.2 tarball and change build to gfortran from gcc42. Tested with the tests directory obtained from...

svn co --username anonymous --password Scilab http://svn.scilab.org/scilab/branches/BUILD_4/tests

using 'cd tests; make tests' in the build directory. Seems to be working well.

[Jack Howarth]

scilab-4.1.2-1000 info file

[Jack Howarth]

Logged In: YES
user_id=403009
Originator: YES

File Added: scilab.patch

[Jack Howarth]

scilab-4.1.2-1000 patch file

[Jean-François Mertens]

Logged In: YES
user_id=477035
Originator: NO

Please jack could you make a unified info file (varianted)
for scilab and scilab-atlas ?
Saves so much on maintenance ...

Jean-Francois

[Jean-François Mertens]

[Jean-François Mertens]

Logged In: YES
user_id=477035
Originator: NO

In absence of reply, I created one.
Attaching it here, together with the corresponding
patch file (only a minute difference there).

One of the reasons such a unified file saves, is that
in general fixes to one are also useful to the other...

So please could you review this very carefully,
(from the "non-atlas" point of view if you prefer _ I'll
do then the same from the atlas point of view in the
next few days).

In particular, for the following 2 points :

A) deps and builddeps: exactly correct?
Especially xaw3d and libsablot
I've not sufficient evidence; further I did not check that
if scilab is built in the presence of all deps and builddeps
of scilab-atlas, it still gives exactly the same build as
when built on a "naked" fink installation.

The following little script is often useful for this:

# cat ~/bin/otool_deps
#!/sw/bin/bash
# `otool_deps <pkgs>` is the (possibly empty, alphabetically sorted, comma-separated) list of pkgs,
# except for those in the argument list, followed by a newline, on which those in the argument list depend according to otool -L.
dpkg -L $@|xargs file|fgrep 'Mach-O'|cut -f1 -d:|xargs otool -L 2>/dev/null|egrep -v ':$'|sort -u|sed -e 's,[[:space:]]\+,,' \ -e 's, .*,,'|xargs dpkg -S 2>/dev/null|cut -f1 -d:|sort -u|fgrep -vx "`tr ' ' '\n' <<<$*`"|xargs|sed -e 's; ;, ;g'

(just removed here the aspects that needed fink's sed, fink's sort and grep (coreutils-default and grep pkgs)

: all listed packages must be among the recursive deps, and the -dev packages correspoding to all listed packages must be among the builddeps.

B) all little fixes: is each one still needed ? or just correct but not strictly indispensable ?
or has become essentially incorrect because the source takes corresponding precautions ?

Thanks a lot in advance !

JF

PS: After that, there will remain to find a mechanism for lpsolve-scilab to interact properly
with this package (cf second point in DescPackaging of lpsolve-scilab).
And I may want to put in a revision of atlas just before, splitting the dylib into its 4
traditional parts _ since else that would require another rev-up for scilab-atlas.

Even this tiny upgrade from 4.1.1 to 4.1.2 will require me to revise lpsolve-scilab :
something has changed in scilab's build-system, and lpsolve-scilab no longer
builds properly ..
How I'd wish to get rid of that pkg .. !
File Added: scilab.info

[Alexander Hansen]

Logged In: YES
user_id=353035
Originator: NO

I guess I'll take scilab over; I can run the dependency check.

[Martin Costabel]

Logged In: YES
user_id=60552
Originator: NO

I had a look at jfm's revision 1001. Some remarks:
1. I got a couple of syntax errors from the variants stuff, so I changed this at a few places.
2. The special compilation of dlamch.o and slamch.o is still necessary. This version takes care by default of dlamch.o by compiling it without optimization (I find -O2 -ffloat-store more elegant, because it leaves some optimization in place, and it displays the root of the problem). So we don't need to treat dlamch.o apart. But they forgot slamch.o, so we still need to treat it. I don't remember how the infinite loop for that one is triggered, but I remember that I introduced this part of the patch script after I got bitten by the bug. In more recent svn versions of scilab, they take care of both dlamch.o and slamch.o
3. I did not try the atlas variant, but the standard variant compiles and runs OK, although I did not perform any special testing.
4. The version I used is attached as revision 1002.

File Added: scilab.info

[Martin Costabel]

scilab-4.1.2-1002