Package Details: openmodelica-git 1.16.0.dev.r590.g8f5710f752-2

Git Clone URL: https://aur.archlinux.org/openmodelica-git.git (read-only, click to copy)
Package Base: openmodelica-git
Description: The Open Source Modelica Suite
Upstream URL: https://openmodelica.org
Licenses: OSMC-PL
Conflicts: openmodelica, openmodelica-dev, openmodelica-svn
Provides: openmodelica
Submitter: Xwang
Maintainer: ElMastro
Last Packager: ElMastro
Votes: 10
Popularity: 0.083533
First Submitted: 2015-06-20 11:21
Last Updated: 2021-02-13 23:23

Dependencies (18)

Required by (0)

Sources (10)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 ... Next › Last »

Xwang commented on 2020-07-30 19:26

Here:

https://pastebin.com/bZdCHk7z

you find a modified PKGBUILD which solves those last issues (except for the qwt_plot.h: No such file or directory issue). Maybe once the PKGBUILD is updated we can open a bug pointing to this PKGBUILD as a way to reproduce the makepkg bug (if you have not done that already).

Xwang commented on 2020-07-30 17:40

@ElMaestro

I've tried your latest PKGBUILD.

I've noted the following: 1) namcap saysa that some dependencies are not needed and some need are missing:


openmodelica-git E: Dependency python2 detected and not included (programs ['python2'] needed in scripts ['opt/OpenModelica/lib/omlibrary/SolarTherm 0.2/Resources/Include/st_test_ext.py'])
openmodelica-git E: Dependency lib32-zlib detected and not included (libraries ['usr/lib32/libz.so.1'] needed in files ['opt/OpenModelica/lib/omlibrary/Buildings latest/Resources/Library/linux32/libpython2.7.so.1.0'])
openmodelica-git E: Dependency lib32-gcc-libs detected and not included (libraries ['usr/lib32/libgcc_s.so.1'] needed in files ['opt/OpenModelica/lib/omlibrary/Buildings latest/Resources/Library/linux32/libpython2.7.so.1.0'])
openmodelica-git W: Dependency included and not needed ('boost-libs')
openmodelica-git W: Dependency qt5-svg included but already satisfied
openmodelica-git W: Dependency included and not needed ('qt5-tools')
openmodelica-git W: Dependency included and not needed ('antlr4-runtime')

2) an empty OMSens folder is still created under pkg/openmodelica-git/usr/

3) the pkg/openmodelica-git/usr/share/openmodelica/icons/ folder should be in pkg/openmodelica-git/opt/OpenModelica/share/icons/ (the paraview-opt package puts the icons under the pkg/paraview-opt/opt/paraview/share/icons/ )

ElMastro commented on 2020-07-29 22:51

I'm getting the same errors. Would you like to try if the PKGBUILD in PKGBUILD ?

Xwang commented on 2020-07-28 11:15

@ElMastro In my opinion it is better to install OMSens in a /opt/OpenModelica subfolder and modify the OMSens setting with a patch file (if it is a textual file) or warn the user at the end of the installation about the need to make such a change. In such a way the systems is more clean.

ElMastro commented on 2020-07-28 10:40

@Xwang, You are right. The "--without-ipopt" option allows to utilize the external ipopt, which mumps should work fine, so the dependency will be corrected in the next PKGBUILD.

About the location of OMSens we can of course change it, but this would make it not work 'out of the box', and the user would have to set the path on the OMSens settings.

Xwang commented on 2020-07-27 06:06

@ElMastro

It seems strange that OMSens is the only package in the whole operating system that installs something directly under /usr . All the other packages install in one ore more of the /usr subfolders

As far as the ipopt, I see that in the build.sh there is the --without-ipopt option. If I remember correctly this option excludes the use of the internal provided ipopt and search for an already available one in the system. Is it so?

ElMastro commented on 2020-07-26 22:22

@Xwang: 1) it appears that coin-or-ipopt is where it gets some problems. It depends most probably on the Fortran GUI. 2) I can't recreate this problem, on my system qwt_plot.h is in the qwt package. 3) Filing a Bug is probably a way; this is another confirmation.

About the icons the problem is in the package part (all the "install -D -m644") so if we understand the script works I can change this part easily. I do believe OMSens should stay in the /usr as implied in the openmodelica settings.

Xwang commented on 2020-07-26 09:55

Moreover I've seen that the build.sh contains --prefix=/opt/OpenModelica, but then the package function copies things in the /usr so I wonder if we want to put OpenModelica in /opt or in /usr

Xwang commented on 2020-07-26 09:10

Today I've tried again building the PKGBUILD taken from the pastebin link date 2020-06-27.

I can confirm that: 1) coin-or-ipopt must be added to the depends list 2) makepkg gives the "PlotWindow.h:35:10: fatal error: qwt_plot.h: No such file or directory" 3) however executing this procedure: a) execute makepkg -o b) then manually compile executing in a bas the same commands which are in the build() function c) execute makepkg -R a package is made. So while this semi manual procedure seems to be able to at least turn around the makepkg build issue, should we open a bug versus makepkg because it is not compiling something which is compilable in a terminal?

Moreover executing namcap:

namcap openmodelica-git-1.16.0.dev.r267.g0c0d97d31-3-x86_64.pkg.tar.xz openmodelica-git E: ELF file ('usr/OMSens/old/fortran/tmp/SystemDynamics.WorldDynamics.World3.Scenario_1') outside of a valid path. ...

I get messages which highlight that a lot of things (icons and OMSens folders) are installed under usr instead that /opt/OpenModelica.

Finally the makepkg -R printed a lot of warning like this:

strip: ./opt/OpenModelica/lib/omlibrary/Buildings latest/Resources/Library/win64/ModelicaBuildingsPython3.6.lib(ModelicaBuildingsPython3.6.dll): recognised but unhandled machine type (0x8664) in Import Library Format archive

Can we avoid building also the windows libraries?

ElMastro commented on 2020-07-13 16:20

@ppenguin: Now I understand. I don't know what to do because I'm pretty sure makepkg shouldn't make that difference.

In particular if 'make' command gives different results inside or outside the makepkg environment, I image it will become difficult to make a working PKGBUILD for everybody.

A way to do it could be to start from the .deb package, but I don't think this could be considered a clean solution. I'm giving it a couple more trying to see why this is happening....