[75337] trunk/dports/science/ncarg/Portfile

Ryan Schmidt ryandesign at macports.org
Sat Jan 22 02:08:30 PST 2011

On Jan 22, 2011, at 03:23, takeshi at macports.org wrote:

> Revision: 75337
>          http://trac.macports.org/changeset/75337
> Author:   takeshi at macports.org
> Date:     2011-01-22 01:23:01 -0800 (Sat, 22 Jan 2011)

> Modified: trunk/dports/science/ncarg/Portfile

> +    reinplace "s|int_p_NULL|(int*)NULL|g" ${worksrcpath}/ncarg2d/src/libncarg/ezmap/mapngb.c

This is exactly the kind of change that would be more appropriately made as a patchfile, not a reinplace. The patchfile provides context around where the change is made, so that if the upstream software changes in the future, and the patch needs to be modified, the context in the existing patch can help you identify where in the revised source the changes need to be made; if using a reinplace, you won't get any notification if the reinplace has failed to make the change (unless you apply the MacPorts base patch in #15514). Also, if upstream incorporates this change, with a patch, you'd again get notification the patch failed to apply; with a reinplace, you'll never know unless you go look for yourself every time you update the port. The no-longer-necessary reinplace would not cause any harm, but it would clutter up the portfile.

I could understand using a reinplace if there were hundreds of occurrences to be replaced, which would make for an unnecessarily large patchfile, but in this case, we're talking about changes to a single line of a single file only. Attached is the patch I would suggest the portfile use instead.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-ncarg2d-src-libncarg-ezmap-mapngb.c.diff
Type: application/octet-stream
Size: 599 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110122/12074730/attachment.obj>

More information about the macports-dev mailing list