Re: Set install_name to fix devel/mustach on macOS

[Greg Troxel <gdt%lexort.com@localhost>]

Sijmen Mulder <ik%sjmulder.nl@localhost> writes:

> Hi Greg,
>
>> Op 27 dec. 2019, om 15:42 heeft Greg Troxel <gdt%lexort.com@localhost> het volgende geschreven:
>> 
>> Sijmen Mulder <ik%sjmulder.nl@localhost> writes:
>> 
>>> devel/mustach builds are failing on macOS because no install_name is
>>> set. Attached patch should fix it (and does so on my machine) but
>>> I'd appreciate someone with macOS experience taking a look.
>>> 
>>> Build failure:
>>> https://us-east.manta.joyent.com/pkgsrc/public/reports/Darwin/10.14/trunk/x86_64/20191220.0920/mustach-0.99/install.log
>>> 
>>> Upstream PR:
>>> https://gitlab.com/jobol/mustach/merge_requests/16
>>> 
>>> ok?
>> 
>> I am having trouble following.  The diff upstream and this diff don't
>> look the same.
>
> The Makefile changes should be identical; in fact I generated the
> patch from the git commits. Note that the pull requests is a two parter
> since I made a mistake in the first commit and corrected it with the
> second.
>
>> Also, it seems like upstream does not require gmake, and the patch
>> introduces a gmake dependency.  It would seem our usual approach (beyond
>> an upstream-ok patch) would be  to SUBST something like
>> @installnameflags@ to either what macos needs or empty, depending on OS
>> in our Makefile.
>
> The gmake dependency is unfortunate but for the PR I saw no way (except
> switching build systems entirely) to have a Mac-only flag other than an
> if statement, and those aren't portable between make systems. GNU make
> then seemed like the safest choice.

If upstream merges your PR and documents gmake, that's how it is and
pkgsrc should of course adapt on next update.  It just seems a bit much
as a pkgsrc patch, especially as the freeze is nearing hte end.

> I’m not sure what you mean with the '@installnameflags@' thing (where
> would that be defined?) but a non-patch alternative would be to add a

I meant that pkgsrc has a way to substitute things in files, and the
usual plan is to use @foo@ in the file and then change it to the right
thing with SUBST_SED.

See net/ettercap-NG for an example, although it is not conditionalize by
OS.  There are a a lot of SUBST_

> post-install target on Darwin only that runs
>
>   install_name_tool -d ${PREFIX}/lib/libmustach.so ${PREFIX}/lib/libmustach.so
>
> A quick grep for install_name_tool shows that many packages do this.

In freeze, I would really prefer that, especially given precedent.

Longer term, it would be nice to have some higher-level declarative
workaround.  I suppose this is either a bug in upstreams or a bug in
macos (is install_name covered by any standards?) depending on how you
look at it :-)