Re: [Liborigin-devel] project repository

[Alexander P. <ale...@gm...>]

Hello Stefan,

I hadn't deleted the previous srpms and as a result I spent an hour
building and rebuilding the wrong one, wondering why I'm not getting
the documentation built…
Everything seems fine, I think you can increment that last zero to one
if you want.
Thank you for all your work!

Best regards,
A.


On Tue, May 11, 2021 at 4:47 PM Stefan Gerlach
<ste...@un...> wrote:
>
> Hi Alexander,
>
> thanks. I fixed the GNUInstallDirs, made the doxygen doc build per default and build opj2dat with the dynamic lib if static is disabled in the
> latest commit. I hope that fixes all issues :-)
>
> best
> Stefan
>
>
> On 11/05/2021 16:09, Alexander Ploumistos wrote:
> > Hi Stefan,
> >
> > I had to add "include(GNUInstallDirs)" before "install" in the shared
> > library section, e.g.
> >
> > --- a/CMakeLists.txt    2021-05-11 14:20:57.000000000 +0200
> > +++ b/CMakeLists.txt    2021-05-11 15:52:50.279765255 +0200
> > @@ -86,6 +86,7 @@
> >           VERSION ${PROJECT_VERSION}
> >           SOVERSION ${PROJECT_VERSION_MAJOR}
> >       )
> > +    include(GNUInstallDirs)
> >       install( TARGETS origin_shared
> >           LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
> >       )
> >
> > otherwise the shared object files end up under /usr/lib even on 64-bit
> > arches. I suppose the static library is also affected by this. Can the
> > include statement go to the beginning of the file?
> >
> >
> > The HTML documentation is no longer created, is there an extra
> > configuration/build option I need to specify or did it get eaten up
> > with the latest changes?
> >
> >
> > I don't know anyone using opj2dat by itself, if anyone files a bug
> > report, I'll need to find a way to build it along with the shared
> > libraries, but for now it doesn't matter.
> >
> >
> > Best regards,
> > A.
> >
> >
> > On Tue, May 11, 2021 at 2:34 PM Stefan Gerlach
> > <ste...@un...> wrote:
> >>
> >> Hello Alexander,
> >>
> >> i tried to fix the issues with liborigin in the upstream code. Let me know if there are still issues.
> >> If i get the discussion correctly SciDAVis will also use the upstream version now or at least sync with upstream. Thanks for resolving these issues.
> >>
> >> Best regards,
> >> Stefan
> >>
> >> On 11/05/2021 12:40, Alexander Ploumistos wrote:
> >>> Hello Stefan,
> >>>
> >>> Thank you for taking care of this. It would be great to get a 3.0.1
> >>> release, but not just yet; when I packaged the latest snapshot with
> >>> the commits from SciDAVis, I came across a couple of issues:
> >>> https://github.com/highperformancecoder/scidavis/issues/218
> >>> They are not that important, but I think it would be better to get rid
> >>> of them before the next release. Also, it might be a good idea to
> >>> chime in on the issue or otherwise get in touch with the SciDAVis
> >>> people, so as to avoid doing the work twice. If you get the chance to
> >>> look at these, commit the changes and they can pick them up
> >>> downstream. If they manage to get to them first, they should push them
> >>> upstream.
> >>> The later half of this discussion might also be of interest to you as well:
> >>> https://github.com/highperformancecoder/scidavis/discussions/212
> >>>
> >>> Best regards,
> >>> A.
> >>>
> >>> On Tue, May 11, 2021 at 12:25 PM Stefan Gerlach
> >>> <ste...@un...> wrote:
> >>>>
> >>>> Hello Alexander,
> >>>>
> >>>> i updated upstream liborigin with the latest patches from SciDAVis. I could release a new version 3.0.1 if that's a good idea.
> >>>> LabPlot now uses the system installed liborigin 3 if available.
> >>>>
> >>>> best wishes
> >>>> Stefan
> >>>>
> >>>>> You can see the changes committed to SciDAVis's liborigin submodule here:
> >>>>> https://github.com/SciDAVis/liborigin/commits/
> >>>>> There are some fixes and cleanups and I don't think there's anything
> >>>>> too SciDAVis-centric among them. Some of them will make my life more
> >>>>> difficult as I'll probably need to refactor a few Fedora-specific
> >>>>> workarounds with regard to cmake…
> >>>>>
> >>>>>    From the point of view of a distribution package maintainer it would
> >>>>> be great if all the work happened first in liborigin upstream or if
> >>>>> any changes made downstream were pushed upstream (within a reasonable
> >>>>> timeframe), so as to avoid forking and fragmentation. While git
> >>>>> submodules are appealing, at least to consumers of projects, I think
> >>>>> they tend to complicate things.
> >>>>>
> >>>>> Once you get a chance to look at the code, let me know what you think.
> >>>>>
> >>>>>
> >>>>> Thank you and have a nice weekend,
> >>>>> A.
> >>>>>
> >>>>>
> >>>>> On Sat, May 8, 2021 at 11:09 AM Stefan Gerlach
> >>>>> <ste...@un...> wrote:
> >>>>>>
> >>>>>> Hello Alexander,
> >>>>>>
> >>>>>> i'm not working on SciDAVis but i also would like to see the changes incorporated in liborigin.
> >>>>>> Missing updates of liborigin were the reason why we use a bundled version of liborigin in LabPlot. If nobody cares, i can take a look at
> >>>>>> SCiDAVis liborigin and try to update liborigin. If that works, we can use the official liborigin in LabPlot.
> >>>>>>
> >>>>>> best wishes
> >>>>>> Stefan
> >>>>>>
> >>>>>> On 07/05/2021 23:04, Alexander Ploumistos wrote:
> >>>>>>> Hello Stefan, Miquel,
> >>>>>>>
> >>>>>>> I was about to update the Fedora packages of SciDAVis and its
> >>>>>>> dependencies for which I am the maintainer and I realized that the
> >>>>>>> changes committed to the SciDAVis branch of liborigin have not been
> >>>>>>> incorporated yet into the "official" repository.
> >>>>>>>
> >>>>>>> In theory, the LabPlot should also depend on liborigin, but looking at
> >>>>>>> the spec file, it seems that at some point one of the maintainers
> >>>>>>> switched to the bundled version. Nevertheless, I'd like to abide by
> >>>>>>> Fedora's rules and maintain a separate package - if possible - which I
> >>>>>>> think it should be.
> >>>>>>>
> >>>>>>> Since the two of you are contributing to all of the above projects, I
> >>>>>>> was wondering if you intend to merge the changes from SciDAVis to
> >>>>>>> liborigin, so that there is one upstream source for everything.
> >>>>>>>
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> A.
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Liborigin-devel mailing list
> >>>>>>> Lib...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/liborigin-devel
> >>>>