[macports-ports] branch master updated: macports-notifier: update to more recent version
Ryan Schmidt
ryandesign at macports.org
Mon Oct 16 19:41:22 UTC 2017
On Oct 16, 2017, at 06:51, Sierk Bornemann wrote:
> Am 14.10.2017 um 21:06 schrieb Ryan Schmidt:
>
>> On Oct 14, 2017, at 10:15, Kurt Hindenburg wrote:
>>
>>> Kurt Hindenburg (kurthindenburg) pushed a commit to branch master
>>> in repository macports-ports.
>>>
>>>
>>> https://github.com/macports/macports-ports/commit/75d48de51d565117a1d9c1a8456332f8a21b3f34
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>>
>>> new 75d48de macports-notifier: update to more recent version
>>>
>>> 75d48de is described below
>>>
>>>
>>> commit 75d48de51d565117a1d9c1a8456332f8a21b3f34
>>>
>>> Author: Kurt Hindenburg <khindenburg at macports.org>
>>> AuthorDate: Sat Oct 14 11:10:05 2017 -0400
>>>
>>>
>>> macports-notifier: update to more recent version
>>>
>>> Change to use github repo instead of googlecode.
>>>
>>> I can not really test all the functions on my system due to my setup.
>>>
>>> closes https://trac.macports.org/ticket/47573
>>
>>
>>> + reinplace -q -W ${worksrcpath} "s|/opt/local|${prefix}|g" \
>>> + PNDefines.h \
>>> + net.sourceforge.portsnotifier.plist \
>>> + PNPortWrapper.m \
>>> + PortsHelper.c
>>
>> I suspect you're using "-q" here because your MacPorts prefix is /opt/local, so this reinplace tries to replace /opt/local with /opt/local which does nothing and triggers the warning. While using "-q" is one way to avoid that warning, it prevents you from benefiting from the warning, should the source files change in a future version. The better thing to do is to replace /opt/local with @PREFIX@ in the files, save that diff as a patchfile that the port uses, then have the port use reinplace (without "-q") to change @PREFIX@ to ${prefix}.
>>
>>> + reinplace -q -W ${worksrcpath} "s|/var/log/portsnotifier.log|${prefix}/var/log/portsnotifier.log|g" \
>>> + net.sourceforge.portsnotifier.plist \
>>> + PortsHelper.c
>>
>> You should not need to use "-q" here, since you're specifying a search and replacement that always differ, and you're giving an explicit list of files (it's not like you're trying to reinplace over all *.c files using glob, where some files may contain the string and others may not). Either the string to be replaced exists in the listed files (in which case you should not see a warning), or it does not (in which case you need to update the reinplace or you don't need to be reinplacing in that file).
>
> What for are these both reinplace commands, what is their purpose? Are they required? Could they be omitted with fixing this upstream in the macports-notifier project?
Well, you can see what they do: The first one replaces all occurrences of "/opt/local" with whatever the user's MacPorts prefix is, in the 4 listed files. Most users use the /opt/local prefix, but a different prefix can be set at the time MacPorts is configured, so if we did not do this replacement, the port would be broken for users who have done that. If your project had an autotools-based build system, I would recommend you add a configure argument, Makefile variable, or other way for the MacPorts prefix to be specified at build time; then we would just use that method to set the prefix, and this reinplace wouldn't be needed. However you have an Xcode-based build system, and I'm not certain how best to supply variables to it at build time.
The second reinplace moves the logfile from the system-level /var/log directory to the var/log directory inside the MacPorts prefix. If you hardcoded this to /opt/local/var/log as you hardcode /opt/local elsewhere in your project, then we could pare this down to just the first reinplace and eliminate the second one.
> Besides that:
>
> In the port file, the line
>
> ''patchfiles patch-general.png.diff''
>
> no longer is required, since the little patch for the PortsNotifier.xcodeproj/project.pbxproj file has been committed by me (sierkb) upstream a few minutes ago.
> Please change the port file accordingly.
That can probably wait until the port is next updated for substantive upstream changes. At that time, it will be obvious to the person updating the port that the patch is no longer needed.
More information about the macports-dev
mailing list