#44909: fswatch @1.4.3 update ------------------------------------+--------------------------------- Reporter: enrico.m.crisostomo@… | Owner: ryandesign@… Type: update | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: haspatch maintainer Port: fswatch | ------------------------------------+--------------------------------- Changes (by ryandesign@…): * cc: Thanks. (removed) Comment: 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? -- Ticket URL: <https://trac.macports.org/ticket/44909#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X

#44909: fswatch @1.4.3 update ------------------------------------+--------------------------------- Reporter: enrico.m.crisostomo@… | Owner: ryandesign@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: fixed | Keywords: haspatch maintainer Port: fswatch | ------------------------------------+--------------------------------- Comment (by enrico.m.crisostomo@…): Hi ryandesign@macports.org, 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 -- Ticket URL: <https://trac.macports.org/ticket/44909#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X

#44909: fswatch @1.4.3 update ------------------------------------+--------------------------------- Reporter: enrico.m.crisostomo@… | Owner: ryandesign@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: fixed | Keywords: haspatch maintainer Port: fswatch | ------------------------------------+--------------------------------- Comment (by enrico.m.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. -- Ticket URL: <https://trac.macports.org/ticket/44909#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X

#44909: fswatch @1.4.3 update ------------------------------------+--------------------------------- Reporter: enrico.m.crisostomo@… | Owner: ryandesign@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: fixed | Keywords: haspatch maintainer Port: fswatch | ------------------------------------+--------------------------------- Comment (by larryv@…): I’ve commented on the [https://github.com/emcrisostomo/fswatch/issues/54 upstream issue]. There is no MacPorts problem here; you’re simply using `DESTDIR` where you should be using `prefix`. -- Ticket URL: <https://trac.macports.org/ticket/44909#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X

#44909: fswatch @1.4.3 update ------------------------------------+--------------------------------- Reporter: enrico.m.crisostomo@… | Owner: ryandesign@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: fixed | Keywords: haspatch maintainer Port: fswatch | ------------------------------------+--------------------------------- Comment (by larryv@…): Replying to [comment:7 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 target 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. -- Ticket URL: <https://trac.macports.org/ticket/44909#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X