Re: New Hatari version: need help
2010/6/19 Alexander Boström a...@root.snowtree.se: lör 2010-06-19 klockan 19:32 +0200 skrev Andrea Musuruane: I do not know how should I threat those internal libraries. How should I package them? Because upstream uses static libraries the dynamic versions cmake creates are not versioned. https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libraries I fail to see how this is relevant. Hatari do not use Rpath. Regards, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
On Sat, Jun 19, 2010 at 7:44 PM, Chen Lei supercyp...@gmail.com wrote: You can open a RFE report against this package in bugzilla for review. Can you point me to an example? For internal libs, if those libs are not libs from other project, you can simply use %cmake -DBUILD_SHARED_LIBS:BOOL=OFF to avoid generation of those shlibs. Default place for python ui don't need change. Internal libs are made by Hatari developers and therefore they haven't a different upstream. Thanks! Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
Andrea Musuruane píše v Ne 20. 06. 2010 v 11:25 +0200:
2010/6/19 Alexander Boström a...@root.snowtree.se:
lör 2010-06-19 klockan 19:32 +0200 skrev Andrea Musuruane:
I do not know how should I threat those internal libraries. How should
I package them? Because upstream uses static libraries the dynamic
versions cmake creates are not versioned.
https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libraries
I fail to see how this is relevant. Hatari do not use Rpath.
hatari could use %{_libdir}/hatari with a rpath set for the internal
parts built as shared libraries. The easiest way is to disable building
shared libs when calling cmake as suggested earlier.
Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
New Hatari version: need help
Hi all, a new version of Hatari has recently been released: http://hatari.berlios.de/ The new version drops the old build system based on autotools and now it only support cmake. An (optional) python GUI is now bundled with the emulator. Moreover some static libraries have been introduced and %cmake will output them as dynamic libraries because of -DBUILD_SHARED_LIBS:BOOL=ON is defined in the macro itself. I wonder if this package needs a new review request because of these changes. I do not know how should I threat those internal libraries. How should I package them? Because upstream uses static libraries the dynamic versions cmake creates are not versioned. The python UI by default places python files in /usr/share/hatari/hatariui/. Is this acceptable or should I patch it to place them in /usr/share/hatariui/ ? Thanks in advance for you advices. Regards, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
2010/6/20 Andrea Musuruane musur...@gmail.com: Hi all, a new version of Hatari has recently been released: http://hatari.berlios.de/ The new version drops the old build system based on autotools and now it only support cmake. An (optional) python GUI is now bundled with the emulator. Moreover some static libraries have been introduced and %cmake will output them as dynamic libraries because of -DBUILD_SHARED_LIBS:BOOL=ON is defined in the macro itself. I wonder if this package needs a new review request because of these changes. I do not know how should I threat those internal libraries. How should I package them? Because upstream uses static libraries the dynamic versions cmake creates are not versioned. The python UI by default places python files in /usr/share/hatari/hatariui/. Is this acceptable or should I patch it to place them in /usr/share/hatariui/ ? Thanks in advance for you advices. Regards, Andrea. -- You can open a RFE report against this package in bugzilla for review. For internal libs, if those libs are not libs from other project, you can simply use %cmake -DBUILD_SHARED_LIBS:BOOL=OFF to avoid generation of those shlibs. Default place for python ui don't need change. Chen Lei. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
lör 2010-06-19 klockan 19:32 +0200 skrev Andrea Musuruane: I do not know how should I threat those internal libraries. How should I package them? Because upstream uses static libraries the dynamic versions cmake creates are not versioned. https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libraries /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
