[hatari-devel] Re: Hatari 2.0.0 fails to create symlinks in a chroot

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 11/26/2016 10:58 AM, Andrea Musuruane wrote:
> On Wed, Nov 23, 2016 at 10:57 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> > On 11/18/2016 01:14 PM, Andrea Musuruane wrote:
> > We use mailing list(s) as "bug tracker" (and more persistent ones
> > are listed in Hatari documentation).  Like other bug trackers,
> > you can post bugs there after you've registered.  Registering
> > isn't restricted.
> >
> > Of the mailing lists, on hatari-devel you get few mails every day,
> > on hatari-users, weeks can go without a single mail.
>
> I'm currently subscribed to 19 different mailing lists. I'm sorry but
> I really cannot take more. Please make a bug tracker available.

Our hosting service (tuxfamily.org) doesn't provide
a bug tracking service.


> It is also very difficult to look for current bugs

Known, more generic bugs for v2.0:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/v2.0.0/doc/todo.txt

And compatibility issues:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/v2.0.0/doc/compatibility.html

Latest status you get by checking "tip" instead of "v2.0.0".


> and  patches without one.

What kind of patches you're expecting?


> > > I was updating the Hatari RPM in Fedora to v2.0.0 and I noticed that
> > > mimetype icon symlinks are not created.
> > >
> > > rpmbuild doesn't use absolute paths but is uses a specific destination
> > > directory. The code in share/CMakeLists.txt seems to ignore the
> > > destination directory and it uses absolute paths for symlink creation.
> > > Hence the failure.
> >
> >
> > As you can see, it's not an absolute path, unless you've explicitly
> > specified one for CMAKE_INSTALL_PREFIX, or left it at the CMake
> > default ("/usr/local") value:
> > ---------- share/CMakeLists.txt ----------------
> > ...
> >         foreach(type vnd.msa vnd.fastcopy x-stx)
> >                 install(CODE "execute_process(COMMAND ln -sf
> > application-x-st-disk-image.png
> >
> > ${CMAKE_INSTALL_PREFIX}/${ICONDIR}/${size}/mimetypes/application-${type}-disk-image.png)
> >                                 ")
> >         endforeach()
> > ...
> > foreach(type vnd.msa vnd.fastcopy x-stx)
> >         install(CODE "execute_process(COMMAND ln -sf
> > application-x-st-disk-image.svg
> >
> > ${CMAKE_INSTALL_PREFIX}/${ICONDIR}/scalable/mimetypes/application-${type}-disk-image.svg)
> >                         ")
> > endforeach()
> > ----------- CMakeLists.txt ---------------
> > if(NOT ICONDIR)
> >         set(ICONDIR share/icons/hicolor)
> > ------------------------------------------
> >
> > See:
> > https://cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html
>
> I already do that. But CMAKE_INSTALL_PREFIX is not how you define a
> DESTDIR (which is already set up correctly).

I What the documentation states is that you can use "DESTDIR" to
define (part of) CMAKE_INSTALL_PREFIX (which is the real deal).

Not the other way round.


> Please see the attached build.log to better see what's going on.

Log shows that you're giving absolute path to cmake:
	"-DCMAKE_INSTALL_PREFIX:PATH=/usr"

instead of the relative one you wanted(?).


> Anyway, even if you will correctly add a DESTDIR in the cmake script,
> it will not work because the symbolic link path will no longer be
> there when installing the RPM. It would be easier just to copy the
> same file.

Could you propose a patch?


	- Eero

PS. I'm not that familiar with the Hatari CMake build,
most of it was done by Thomas.