search

mortbopet / Ripes

A graphical processor simulator and assembly editor for the RISC-V ISA
https://ripes.me/
MIT License
2.51k stars 270 forks source link

Building and packaging Ripes using Open Build Service #63

Open surprized opened 3 years ago

surprized commented 3 years ago

I have been learning how to use Open Build Service (OBS) and decided to use Ripes as my first attempt. I managed to make builds for Tumbleweed, Leap and Fedora 33. They are published at home:andresbs.

OBS can fetch files from git repos and build automatically from there, but I decided to instead make a script that clones the latest release, prepares the complete tarball for the build part and modifies the spec file accordingly.

It can also make Appimages in a process similar to the one currently used for Ripes. I will attempt this once I get RPMs working fine.

I am still sorting out issues with the .desktop file for Leap (certain openSUSE conventions), but Tumbleweed and Fedora RPMs seem to build without problems. My Fedora 33 install needs to be updated and I am currently with limited bandwith resources, I'd be happy to know if someone can test that RPM.

Either way, it should be possible to open Ripes from the terminal directly by just running "Ripes".

(see #62)

Edit: adding picture - testing on Tumbleweed - looks like a green light over here Screenshot_20201215_145810

Edit 2: I definitely can't test the i586 or aarch64 builds (waiting for my PinePhone to arrive...). I enabled them for the sake of it, particularly for Ripes it is not an issue since it has nothing essential precompiled and everything can be compiled from source, AFAIK.

surprized commented 3 years ago

RPMs are fully working now. Shortcut included. Now I am trying to figure out how to build the Appimage.

surprized commented 3 years ago

I'll leave this here in case Google, DDG, or whatever happens to find this information: Adding the Appimage target by going to OBS (I'm on the beta) -> Repositories ->Add from a Distribution uses a repo targeting Leap 42.3, which reached EOL, idk, long ago? That happened while following the officlal documentation. The solution was to add the repo "OBS:AppImage/toolchain.leap_15.2" manually, I used the option "Add from a Project" to do this. An example is available at the repo OBS:AppImage:Templates:Leap:15.2/AppImage I think I am reaaaaally close. I basically used the same travis script that is currently used, but it is segfaulting (?)

surprized commented 3 years ago

I got the AppImage build to work and works excellent in openSUSE Leap (KDE) BUT, on Fedora 33 and Ubuntu (live,20.04) I get the like 15 warnings with the same message: qt.svg: Cannot read file ':/icons/info.svg', because: Encoding iso-8859-1 is unsupported (line 1) And so, the program looks like this when running:

Screenshot from 2020-12-16 18-28-34 Maybe this could be fixed by reencoding the svg files as UTF-8? Interesetingly, the OBS AppImage build trims like 10 MB from the Realeases file. I have no idea where those savings come from.

Almost forgot to mention, I had to change to linuxdeploy with the qt plugin because linuxdeployqt wouldn't stop segfaulting... Fedora 33 RPM build works perfectly over here.

EDIT: Build logs and source files are at https://build.opensuse.org/package/show/home:andresbs/ripes and the downloadable files at https://download.opensuse.org/repositories/home:/andresbs/ When running the script update-ripes.sh on a computer with osc installed it does the following:

EDIT2: it seems like the tarball svg files are indeed UTF-8... weird EDIT3: Fixed by removing the svg headers matching iso-8859-1, i.e: <?xml version="1.0" encoding="iso-8859-1"?> becomes <?xml version="1.0"?>

surprized commented 3 years ago

Tested the resulting AppImage on Fedora 33. GUI icons working fine now! If anyone can test the build please let me know the outcome! Ripes-latest-x86_64.AppImage

mortbopet commented 3 years ago

ac5e783 should fix the icon issue (however i assume the script will have to stay as it is until the next release).

the OBS AppImage build trims like 10 MB from the Realeases file.

Is it built in Release or RelWithDebInfo mode?

As a sidenote, a large part of the file size may be attributed to the processor layout files (see https://github.com/mortbopet/Ripes/blob/master/src/processors/layouts.qrc) which are incidentally also highly compressible files. However, these are bundled with the app using the Qt resource system which itself also compress files (see https://doc.qt.io/qt-5/resources.html#compression), so i would be surprised if some 2nd level of compression managed to provide a significant size reduction after the fact. Edit: it might also be some (unnecessary) dll's that gets bundled by when linuxdeployqt creates the appimage that is released on github.

surprized commented 3 years ago

ac5e783 should fix the icon issue (however i assume the script will have to stay as it is until the next release).

That's right, but thanks for letting me know! For the next release I'll remove it.

Is it built in Release or RelWithDebInfo mode?

Release (cmake -DCMAKE_BUILD_TYPE=Release .)

The build script can be found at appimage.yml. All the AppDir files must be located at $BUILD_APPDIR. The build log can be seen at _log, however, only registered users can open it, I think. Instead, you can find it here, if you want to check it; the last command ran at the [707s] mark.

I honestly have absolutely zero idea where those savings come from, but in case you want to compare them. The builds can be compared by mounting them: ./Ripes-0-Build105.1.glibc2.14-x86_64.AppImage --appimage-mount

Late late edit: still fighting my ISP. Tested the aarch64 build on a PinePhone (Phosh) and there is nothing special to say about it, it just works.

surprized commented 3 years ago

Hi, it's me again ;-; I am trying to build from master and tweaked some things from the RPM spec file, now it builds with the following flags for Fedora and openSUSE:

        -DCMAKE_INSTALL_PREFIX:PATH=/usr \
        -DINCLUDE_INSTALL_DIR:PATH=/usr/include \
        -DLIB_INSTALL_DIR:PATH=/usr/lib64 \
        -DSYSCONF_INSTALL_DIR:PATH=/etc \
        -DSHARE_INSTALL_PREFIX:PATH=/usr/share \
        -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 \
        -DCMAKE_BUILD_TYPE=RelWithDebInfo \
        -DCMAKE_C_FLAGS="${CFLAGS:--O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables} -DNDEBUG" \
        -DCMAKE_CXX_FLAGS="${CXXFLAGS:--O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables} -DNDEBUG" \
        -DCMAKE_Fortran_FLAGS="${FFLAGS:--O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables} -DNDEBUG" \
        -DCMAKE_EXE_LINKER_FLAGS=" -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now" \
        -DCMAKE_MODULE_LINKER_FLAGS=" -Wl,--as-needed" \
        -DCMAKE_SHARED_LINKER_FLAGS=" -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now" \
        -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
        -DBUILD_SHARED_LIBS:BOOL=ON \
        -DBUILD_STATIC_LIBS:BOOL=OFF \
        -DCMAKE_COLOR_MAKEFILE:BOOL=OFF \
        -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF \
        -DCMAKE_MODULES_INSTALL_DIR=/usr/share/cmake/Modules

CMake somehow links to a non existant shared object: Ripes: error while loading shared libraries: libripes_lib.so: cannot open shared object file: No such file or directory Do you know where could the problem be?

Edit: found the generated .so at the build folder, but its size is around 80 MB... not sure what happened here...

mortbopet commented 2 years ago

Hey @surprized, @Petross404 is working on adding support for Ripes in Gentoo's Portage package manager (see #141). In doing so, there's going to be some modifications to the top-level cmake file to clean-up how a Ripes install target is defined (#145). Just wanted to let you know, since this might help clean up some of the build files that you've been working with. In general, i'd be interested to see how we can factor out as much common stuff as possible between the different CD paths for Ripes (the existing AppImage generation, @Petross404's Portage work and your OBS work, and the things of #107) and get as much stuff into the Ripes repo to ensure that things are maintained.

surprized commented 2 years ago

Thanks for letting me know, looking forward into this as soon as a new release is out :) The AppImage build from my home repo had to be dropped because OBS wasn't keeping up with the base system, so it could not build. The RPMs for Tumbleweed are still building.