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.
Regards,...
-jmpp
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
