Re: [Liborigin-devel] project repository

[Stefan G. <ste...@un...>]

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
>>>>