fswatch @1.4.3 update

[ryandesign (Ryan Carsten Schmidt)]

The port installs a broken symlink:

lrwxr-xr-x  1 root  wheel     130 Sep  7 19:44 /opt/local/bin/fswatch-run -> /opt/local/var/macports/build/_Users_rschmidt_macports_dports_sysutils_fswatch/fswatch/work/destroot/opt/local/bin/fswatch-run-zsh

Can this be fixed?

[ryandesign (Ryan Carsten Schmidt)]

Actually it was easy to fix. Included in the update in r125150. Filed ​upstream bug report.

[emcrisostomo (Enrico Maria Crisostomo)]

Hi ryandesign@…, but although the patch you applied works for MacPorts, it breaks the functionality of DESTDIR installs. In fact, as I already explained in the issue you opened in fswatch repository here (​https://github.com/emcrisostomo/fswatch/issues/54), this patch breaks DESTDIR installs (that's why the DESTDIR variable is there, in the first place). Why it does not work correctly in MacPorts, I do not know, and that's something I'd ask somebody here at MacPorts to check.

I do not know whether I should ask for this ticket to be opened again or whether to submit another ticket.

Thank you, -- Enrico

[larryv (Lawrence Velázquez)]

Replying to enrico.m.crisostomo@…:

I do not know whether I should ask for this ticket to be opened again or whether to submit another ticket.

Neither. This is an upstream problem.

[emcrisostomo (Enrico Maria Crisostomo)]

Hi larryv, I'm fswatch author and my point is that patch is wrong in the first place. The patch, removing $DESTDIR variable from a Makefile hook, results in the link pointing to /usr/local/bin even when performing a DESTDIR install, which IMHO is plain wrong.

That's why I ask what should be done in a MacPorts port file. Performing a DESTDIR install and expecting symbolic links to point to another location as if DESTDIR weren't specified makes no sense to me.

Thanks for your help.

[emcrisostomo (Enrico Maria Crisostomo)]

Hi larryv@…,

I was checking the Automake literature and funnily enough, page 131 of the latest Automake manual agrees literally with the original sources:

For instance, here is how to create a hard link to an installed program:
     install-exec-hook:
             ln $(DESTDIR)$(bindir)/program$(EXEEXT) \
                $(DESTDIR)$(bindir)/proglink$(EXEEXT)

If the link is broken after the package is built and moved into place, I really don't know why, and I'm inclined to think it's a MacPorts peculiarity, if not quirk. And since I'm no MacPorts experts, I'm asking for help here.

Thanks again.

[larryv (Lawrence Velázquez)]

I’ve commented on the ​upstream issue. There is no MacPorts problem here; you’re simply using DESTDIR where you should be using prefix.

[emcrisostomo (Enrico Maria Crisostomo)]

Thanks larryv, I just answered you on that issue: I see the problem. I'll fix the Makefile upstream and I'll push another Portfile.

[larryv (Lawrence Velázquez)]

Replying to enrico.m.crisostomo@…:

I was checking the Automake literature and funnily enough, page 131 of the latest Automake manual agrees literally with the original sources:

For instance, here is how to create a hard link to an installed program:
     install-exec-hook:
             ln $(DESTDIR)$(bindir)/program$(EXEEXT) \
                $(DESTDIR)$(bindir)/proglink$(EXEEXT)

If the link is broken after the package is built and moved into place, I really don't know why, and I'm inclined to think it's a MacPorts peculiarity, if not quirk. And since I'm no MacPorts experts, I'm asking for help here.

This is understandably confusing. Note that the bit that you quoted from the Automake manual is for making a hard link, not a symbolic link. A hard link does not break if the source is moved, but a symbolic one does. Indeed, the example must use the DESTDIR’d source because the final source file does not exist when the install-exec-hook target is run.