On 22 Oct 2007, at 18:26, Ryan Schmidt wrote:
On Oct 22, 2007, at 02:12, Juan Manuel Palacios wrote:
On Oct 21, 2007, at 5:28 PM, Ryan Schmidt wrote:
On Oct 21, 2007, at 13:38, N_Ox wrote:
Le 21 oct. 07 à 20:15, [EMAIL PROTECTED] a écrit :
Revision 30149 Author [EMAIL PROTECTED] Date 2007-10-21
11:15:29 -0700 (Sun, 21 Oct 2007) Log MessageAdd a patch to
xml2po that, against all reason, seems to work. Bump the
revision number so everyone gets it.
Shouldn't the patch be renamed "patch-xml2po_xml2po.py"?
http://geeklair.net/new_macports_guide/#development.patches.source
It should be called "patch-xml2po_xml2po.py.diff". The guide
should be updated to recommend this style.
I object to naming patchfiles with the original file's extension.
The file "patch-xml2po_xml2po.py" is *NOT* a Python file! It is a
difference of two Python files. Editors attempting to perform
source code highlighting based on the file extension will do so
incorrectly for files which are in fact diffs. Call the file what
it is. Put ".diff" at the end.
The old guide was contradictory, as it recommended one way in one
place and the other way in another place. Let's please
standardize on the format "patch-FOO.diff". According to "find . -
name 'patch-*.diff' | wc -l" we already have hundreds of
patchfiles following this convention.
I support advertising this format as the "recommended" one for
patchfiles, absolutely! (and not "<something>.patch" since the
"patch-<something>.diff" format already conveys both the "patch"
and "diff" messages -- two birds with one stone, as we say
here ;-). But why do I say "recommended"? 'Cause obviously
Portfile writers are gonna come asking why we demand something in
our guide and yet other naming styles exist in our ports tree...
'cause it just aint true that we're gonna rename all patchfiles
that don't follow the convention and adapt the corresponding
Portfiles to work with the new names.
So lets make this format our "official advice", but I would
refrain from *demanding* it just yet.
And with respect to patchfile reach, I still favor and support
the "one patchfile per fix" convention, meaning a single patchfile
can touch as many source files as it takes to fix a particular
problem if need be, no need to make separate patchfiles for each
source file if it's the same problem. Different fixes of course
*must* go in different patchfiles. Based on this, the <something>
part in the "patch-<something>.diff" format can either stand for
the name of the file we're patching (including its extension), if
we're patching a single file (e.g. patch-main.c.diff), or a string
hinting the problem we're fixing with the patch (e.g. patch-
darwin_defines.diff), in case we touch multiple files. These
guidelines immediately lead to a clash in case a single file needs
fixes for multiple, logically different problems, however; in this
case I'd say it's OK to have "patch-problem1.diff" and "patch-
problem2.diff" patchfiles for this sole hypothetically problematic
source file.
Sure, there are no demands, just recommendations. :) nox has
already updated "port lint" to complain about portfiles that don't
match the recommendation. So as people run "port lint" on their
portfiles, hopefully they will be encouraged to fix the names of
their patchfiles.
IIRC, the old guide did recommend one patch file per source file
being patched, but I fully support your recommendation of one patch
file per issue being fixed. Let's get that in the guide too, if
it's not there already.
I have one concern about this: how do we which order patch files will
be applied against a given file? I can see where a diff's 3 lines of
context overlap another diff's modifications, and if applied in the
wrong order, can cause problems...
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood
[EMAIL PROTECTED]
http://shyramblings.blogspot.com
"The rules are simple: The ball is round. The game lasts 90 minutes.
All the
rest is just philosophy."
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
