Menu

SciDAVis Fedora copr - need help unbundling liborigin

2017-06-27
2017-06-27
  • Alexander Ploumistos

    Hello Dr. Standish,

    SciDAVis was retired in Fedora about a year ago, when builds started failing because of incompatibilities with newer versions of gcc and the compiler flags enabled by default in the distribution. I had kept a VM with the last version I could get to work on F23 for my own needs and whenever I had time, I tried to patch things up and get it working again on current OS versions.

    Thankfully, you released version 1.17 and then 1.18 which both worked with minimal effort on my part and rendered a number of patches obsolete.

    I have set up a copr for SciDAVis with builds for Fedora 25, 26 & 27:
    https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/
    (you can find the spec file in each build's details)

    I've also had a few friends who work a lot with plots, enable the copr on their systems and so far no one has reported any regressions or bugs.

    Eventually, I would like to resubmit the package to the official Fedora repositories, but first I would like to unbundle liborigin and package it separately. I have already done the latter, using git snapshots and packaging it as liborigin3 (I noticed that the major version was bumped to 3 in the makefile), which you can find in the copr above. However, on one hand the code has evolved quite significantly while on the other, I have no experience with Qt and frankly with any project with this level of complexity. For the past couple of weeks I have been trying to figure out the logic of the templates while reading the qmake manual and examining Christian Dersch's (aka lupinix, the previous SciDAVis maintainer in Fedora) patches. I hate admitting defeat, but it's high time I did, as I can't get a single build to both succeed and include the unbunbled liborigin3…

    Would you be so kind as to tell me which references to liborigin in which files I need to modify and to what, so that the system library gets used in its place? Christian's spec file for version 1.D8 had the 3rdparty/liborigin directory removed in the prep stage and there was no “CONFIG+=liborigin” option in the build section, however (unless I remember wrong) Origin import worked. I've been going with -lorigin3 and /usr/include/liborigin3 for the library and the path accordingly, but I always get something that looks for the library in 3rdparty/liborigin and the build dies right there.

    Truly grateful for your work,
    Alexander Ploumistos

     
  • gbm

    gbm - 2017-06-28

    Please check attached patch. Note that you have to apply it to commit 7c6e07df of
    https://github.com/highperformancecoder/scidavis. Also you have to use the liborigin3 code of the same commit (7c6e07df) for the liborigin3 rpm package.
    You will have to adjust the BuildRequires of your spec files: boost-devel is no longer required for liborigin3 nor for scidavis, and scidavis.spec requires liborigin3-devel.
    Enjoy,
    Miquel Garriga

     
  • Alexander Ploumistos

    I can't thank you enough, nor can I put into words how happy I was when I read your reply!

    I had two out of three right in my own patch, but I completely botched scidavis/sciadavis.pro, it never occurred to me to remove that section, I added references to the system library and path.

    At first the build kept failing and the error message wasn't very helpful, but I managed to track it down to some extraneous dollar signs and backslashes in config.h.in, see attached patch.

    I noticed that during compilation, something instructed g++ to include the bundled library (-I../3rdparty/liborigin), so I removed it completely during the prep stage and no one complained that it wasn't there.

    I have new builds of both packages in copr and all is well. Yaaayyyy!

    Will the changes made in the bundled library get merged back into liborigin upstream?

    Many, many thanks!
    Alexander Ploumistos

     

Log in to post a comment.