Package Details: java-matlab 1:R2025a.25.1.0.2943329-6

Git Clone URL: https://aur.archlinux.org/matlab.git (read-only, click to copy)
Package Base: matlab
Description: A high-level language for numerical computation and visualization (Java components)
Upstream URL: https://www.mathworks.com/products/matlab.html
Keywords: computation matlab numerical visualization
Licenses: custom:MATLAB EULA
Provides: java-matlab-version
Submitter: ido
Maintainer: vitaliikuzhdin
Last Packager: vitaliikuzhdin
Votes: 41
Popularity: 0.80
First Submitted: 2015-08-15 09:33 (UTC)
Last Updated: 2025-06-25 09:52 (UTC)

Dependencies (5)

Required by (1)

Sources (1)

Pinned Comments

Latest Comments

« First ‹ Previous 1 .. 20 21 22 23 24 25 26 Next › Last »

daniel_shub commented on 2015-12-30 16:51 (UTC)

I came up with the dependency list using a combination of namcap and my own test suite (basically the things listed on the Arch Wiki). I run namcap and remove any dependency it says is included and not needed and add any dependency it says is not included. I then run my test suite in a clean chroot. I then find the minimum set of packages needed to pass the suite and add them as dependencies. I do not keep a list of which dependencies are needed to pass the test suite. I do know that namcap does not think the libxp, libxpm, and ncursues5-compat-libs packages are needed, but they are needed to pass my test suite. My test suite is not comprehensive, so while namcap may be picking up dependencies that are not needed, passing the test without a namcap detected dependency, does not mean the dependency is not needed by some untested MATLAB function. At some point I would like to go through the namcap output and use that to build a better test suite so I could tell you the exact behavior that would demonstrate why a dependency is included. In regards to the gconf package, I can uninstall it and the test suite still passes. In otherwords, the gconf package is a dependency because namcap says it is needed. Specifically, namcap says: matlab E: Dependency gconf detected and not included (libraries ['usr/lib/libgconf-2.so.4'] needed in files ['opt/tmw/matlab/bin/glnxa64/libcef.so', 'opt/tmw/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/components/libmozgnome.so', 'opt/tmw/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/components/libnkgnomevfs.so'])

kyak commented on 2015-12-30 14:42 (UTC)

@daniel_shub: how did you come up with the list of package dependencies? For example, gconf - why is it needed? I don't have most of these packages, and doesn't seem to have problems. I'm installing manually, and just came across this PKGBUILD.

daniel_shub commented on 2015-10-26 16:18 (UTC)

@flying-sheep that is a real pain. I am not sure what the best strategy is. One option is to just not create the links at all and let people add /opt/tmw/matlab/bin to $PATH. I think mmex is confusing. I am also worried that deploytool, mbuild, and mcc might also end up with eventual name clashes. Maybe going with something like mex-matlab. For now, the workaround is pretty simple. You can delete "mex" from line 76 of the PKGBUILD or change "${pkgdir}/usr/bin/${_executable}" to "${pkgdir}/usr/bin/${_executable}-matlab" on line 77.

flying-sheep commented on 2015-10-26 13:22 (UTC)

much better yeah! my only problem is that /usr/bin/mex exists in texlive-bin – maybe we should rename matlabs “mex”? (into ‘mmex’ or something)

daniel_shub commented on 2015-10-22 22:31 (UTC) (edited on 2015-10-22 22:31 (UTC) by daniel_shub)

I have rewritten the PKGBUILD such that it now only supports the most recent version of MATLAB. I have also created version specific packages back to r2010b (https://aur.archlinux.org/packages/?O=0&SeB=n&K=matlab&outdated=&SB=n&SO=a&PP=50&do_Search=Go). If you want to install an older version, use one of the version specific packages. This change makes the PKGBUILD must easier to maintain and understand.

nivata commented on 2015-10-05 14:07 (UTC)

@daniel_shub When I run the command you gave it outputs 'false'. And I have Matlab 2015a installed using a modified version of this PKGBUILD: https://gist.github.com/anonymous/af28f52e890444dd643f Not sure how this helps though?

ido commented on 2015-09-25 21:44 (UTC)

@daniel_shub That's a great idea. I'd suggest using split packages and meta packages for this. For example, we can have the base package in the split package named "matlab" be a meta package for the latest version, and have it be a split package that generates all the matlab-r$versions ones... Shoot me an email and we can figure out if it's easier to do this via github PRs or comaintainership?

daniel_shub commented on 2015-09-25 21:42 (UTC)

I have been unable to get hardware based opengl working since r2014b and the switch to HG2. This has slowed me down from updated the PKGBUILD. I have tried it on different hardware, so I think it is either a missing package or a configuration issue. Can anyone get $ matlab -nodesktop -nosplash -r "opengl info; exit" | grep Software to output false with r2014b or newer?

daniel_shub commented on 2015-09-25 21:37 (UTC)

@ido I am happy to help out again. I never really intended to let it slip as bad as I did. I have never really been happy with the PKGBUILD and it is not the one I use. I think I tried to make it do too much in an attempt to avoid making multiple packages. I propose we simplify the PKGBUILD to only handle the current release and then create packages like matlab-r2015b, matlab-r2015a, ... matlab-r2010b for people who want older versions. This is in fact how I actually manage my installations of MATLAB so it would be simpler for me.

daniel_shub commented on 2015-09-25 21:33 (UTC)

@SibrenVasse I can build an uncompressed package with only a base MATLAB installation in about 10 minutes on my laptop. Adding toolboxes adds time. It takes me a couple of hours to build and compress the package with all the MATLAB toolboxes. The final package can be upwards of 5 GB.

« First ‹ Previous 1 .. 20 21 22 23 24 25 26 Next › Last »