patch instead of reinplace?
Hi, I find reinplace easier and less work for new releases. Are there reasons to use one over the other? Kurt Revision: 125845 https://trac.macports.org/changeset/125845 Author:ryandesign at macports.org https://lists.macosforge.org/mailman/listinfo/macports-changes Date: 2014-09-27 08:41:26 -0700 (Sat, 27 Sep 2014) Log Message: --- chromaprint: use patchfile instead of reinplace ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: patch instead of reinplace?
On Sat, Sep 27, 2014 at 11:59 AM, Kurt Hindenburg kurt.hindenb...@gmail.com wrote: Hi, I find reinplace easier and less work for new releases. Are there reasons to use one over the other? reinplace is appropriate for replacing self-contained tokens and such. When the context of an edit is important, reinplace handles context very poorly, while patch is designed to handle it and fail if the context can't be rationalized (e.g. by detecting that something moved but is otherwise the same). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: patch instead of reinplace?
On Sep 27, 2014, at 11:06 AM, Brandon Allbery wrote: On Sat, Sep 27, 2014 at 11:59 AM, Kurt Hindenburg wrote: Hi, I find reinplace easier and less work for new releases. Are there reasons to use one over the other? reinplace is appropriate for replacing self-contained tokens and such. When the context of an edit is important, reinplace handles context very poorly, while patch is designed to handle it and fail if the context can't be rationalized (e.g. by detecting that something moved but is otherwise the same). Normally, if you're making a change that doesn't involve a MacPorts variable, you'll use a patchfile. If you're making a change that does involve a MacPorts variable, you'll use a patchfile to insert a placeholder (e.g. @PREFIX@), then use a reinplace to change the placeholder to its real value. Remember from https://trac.macports.org/ticket/15514 that if a reinplace fails, there's currently no notice. This can mean that old bugs which were fixed with a reinplace can resurface if a port is updated and the reinplace is not adjusted. With a patch, this can't happen, since if the patch fails to apply, the build will stop with an error. Patches provide context to the reader to let them know what's being changed. This makes it easier to see how the patch needs to be changed if a new version of the code changes things. Patches are easy to send to upstream developers. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
imake
I'm going to try to work on the imake problem, specifically that ports using imake fail with Xcode 5 and up because they require a cpp with traditional cpp support which clang doesn't have. In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. Let me know if you have any objections to this proposal or if you have other ideas how to solve this problem. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
[125841] trunk/dports/games/crafty/Portfile
Revision: 125841 https://trac.macports.org/changeset/125841 Author: khindenburg at macports.org Date: 2014-09-27 07:32:31 -0700 (Sat, 27 Sep 2014) Log Message: --- crafty: add license (Unknown) Modified Paths: -- trunk/dports/games/crafty/Portfile Modified: trunk/dports/games/crafty/Portfile === --- trunk/dports/games/crafty/Portfile2014-09-27 14:30:59 UTC (rev 125840) +++ trunk/dports/games/crafty/Portfile2014-09-27 14:32:31 UTC (rev 125841) @@ -7,6 +7,7 @@ categories games version 24.1 platforms darwin +license Unknown Unknown means that nobody has checked what the license is. If there is no mention of a license anywhere in the source or docs, use none. Note that this means that default copyright restrictions apply, i.e. we can't distribute the software because we lack the copyright holder's permission. This means that the port must be excluded from mirroring. Please get clarification from upstream about terms for redistribution if at all possible. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 12:15 , Ryan Schmidt wrote: I'm going to try to work on the imake problem, specifically that ports using imake fail with Xcode 5 and up because they require a cpp with traditional cpp support which clang doesn't have. In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. Let me know if you have any objections to this proposal or if you have other ideas how to solve this problem. It would be better to fix the macros in xorg-cf-files or wherever so they work with a modern preprocessor. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sat, Sep 27, 2014 at 11:12 PM, Joshua Root j...@macports.org wrote: It would be better to fix the macros in xorg-cf-files or wherever so they work with a modern preprocessor. This probably isn't possible; the issue is that a modern preprocessor speaks C / C++, not Makefile. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 13:14 , Brandon Allbery wrote: On Sat, Sep 27, 2014 at 11:12 PM, Joshua Root j...@macports.org mailto:j...@macports.org wrote: It would be better to fix the macros in xorg-cf-files or wherever so they work with a modern preprocessor. This probably isn't possible; the issue is that a modern preprocessor speaks C / C++, not Makefile. That isn't the issue AFAICT, it's just doing things with comments that were probably undefined before and now don't work: /opt/local/lib/X11/config/Imake.tmpl:2144:10: fatal error: ' X11 .rules' file not found #include ProjectRulesFile ^ /opt/local/lib/X11/config/Imake.tmpl:2142:35: note: expanded from macro 'ProjectRulesFile' # define ProjectRulesFile Concat3(,TopLevelProject,.rules) ^ /opt/local/lib/X11/config/Imake.rules:256:23: note: expanded from macro 'Concat3' #define Concat3(a,b,c)a/**/b/**/c ^ 1 error generated. It wants this to expand as: #include X11.rules but instead it expands as #include X11 .rules The gcc manual says you can use ## for pasting, but the result has to be a valid token. Hence: error: pasting and TopLevelProject does not give a valid preprocessing token - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sat, Sep 27, 2014 at 11:47 PM, Joshua Root j...@macports.org wrote: That isn't the issue AFAICT, it's just doing things with comments that were probably undefined before and now don't work: That is in fact closely related to the issue. The old KR preprocessor allowed that as a hack; ANSI C required that comments expand to spaces, and provided new # and ## operations for token splicing --- but these require valid C tokens. # define ProjectRulesFile Concat3(,TopLevelProject,.rules) may happen to work if you update it to use ANSI token splicing --- but I doubt it, since it's designed for valid C tokens and you're trying to generate a single invalid C token. Also watch what happens with single quoted strings when xmkmf expands macros in Imakefiles. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 13:55 , Brandon Allbery wrote: On Sat, Sep 27, 2014 at 11:47 PM, Joshua Root j...@macports.org mailto:j...@macports.org wrote: That isn't the issue AFAICT, it's just doing things with comments that were probably undefined before and now don't work: That is in fact closely related to the issue. The old KR preprocessor allowed that as a hack; ANSI C required that comments expand to spaces, and provided new # and ## operations for token splicing --- but these require valid C tokens. # define ProjectRulesFile Concat3(,TopLevelProject,.rules) may happen to work if you update it to use ANSI token splicing --- but I doubt it, since it's designed for valid C tokens and you're trying to generate a single invalid C token. It does, with a little tweaking. But you're still right, it then proceeds to screw up the indentation in the Makefile. Also watch what happens with single quoted strings when xmkmf expands macros in Imakefiles. Yeah, that's already been patched. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 12:15 , Ryan Schmidt wrote: In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. Why? My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. What's wrong with adding the dependency to the imake port on the affected platforms? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sun, Sep 28, 2014 at 12:28 AM, Joshua Root j...@macports.org wrote: It does, with a little tweaking. But you're still right, it then proceeds to screw up the indentation in the Makefile. Yeh. I got to know this stuff all to well trying to deal with Haskell's use of CPP --- Haskell tokens just aren't compatible with C tokens, and there simply is no way to reconcile them in a way that wil alow clang's CPP to work properly in all cases. Some of those same screw cases come up here as well, but at least you're spared the really nasty ones like the way single quotes are sometimes Char literals, sometimes word characters, and then there's Template Haskell's use of prefix '' for Lisp-style quoting of types. My conclusion then was the same as now: ANSI CPP wants to be used on C, and is completely unsuited for anything else. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
