Closed
Bug 409956
Opened 17 years ago
Closed 17 years ago
Python preprocessor ignores #filter emptyLines
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: kairo, Assigned: Pike)
Details
(Keywords: fixed1.9.0.2)
Attachments
(1 file)
3.70 KB,
patch
|
ted
:
review+
samuel.sidler+old
:
approval1.9.0.2+
|
Details | Diff | Splinter Review |
Bug 409805 comment #2 talks of a case that would have worked with the perl preprocessor but doesn't work with the python version (AFAIK I had tried both versions when working on bug 397246):
|#filter emptyLines| should remove all the empty lines until |#unfilter emptyLines| but the python preprocessor seems to ignore that.
Assignee | ||
Comment 1•17 years ago
|
||
It's implemented inhttp://mxr.mozilla.org/mozilla/source/config/Preprocessor.py#376.
I wonder if there's a line endings problem in that defines.inc.
![]() |
Reporter | |
Comment 2•17 years ago
|
||
We had that with multiple incarnations of that file, and it's always unix line endings from what I can tell...
Assignee | ||
Comment 3•17 years ago
|
||
I found the problem, and I have a patch and a test case offline. I'll attach that next year.
Assignee: nobody → l10n
![]() |
Reporter | |
Comment 4•17 years ago
|
||
It's been "next year" now for some time, did this patch get lost? I saw today that we are running into the same problem with normal SeaMonkey langpacks :(
Assignee | ||
Comment 5•17 years ago
|
||
So the basic culprit was that the do_filter routine returned an empty string, and write appended a line ending.
Now I do a replace, so empty stays empty.
Going through this, I moved over to open with 'rU' for universal line ending support, which reads in files correctly independent of OS line endings, and converts them to '\n', which makes the checks easier. That only works for real files, though, it seems.
Added a few tests to verify the behaviour here, too.
Attachment #322570 -
Flags: review?(ted.mielczarek)
Updated•17 years ago
|
Attachment #322570 -
Flags: review?(ted.mielczarek) → review+
Assignee | ||
Comment 6•17 years ago
|
||
Marking FIXED, http://hg.mozilla.org//mozilla-central/index.cgi/rev/4157b3484b8e.
Robert, you want this on CVS trunk, right?
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: wanted1.9.0.x?
Resolution: --- → FIXED
![]() |
Reporter | |
Comment 7•17 years ago
|
||
Yes, please, at least for the time being where SeaMonkey (and others) are all still based on CVS.
Assignee | ||
Comment 8•17 years ago
|
||
Comment on attachment 322570 [details] [diff] [review]
use universal line ending io and replace lineending, don't add
This stuck on mozilla-central, I'd like to land it on cvs trunk, too.
Attachment #322570 -
Flags: approval1.9.0.1?
Updated•17 years ago
|
Attachment #322570 -
Flags: approval1.9.0.1? → approval1.9.0.2?
Comment 9•17 years ago
|
||
Robert, since SeaMonkey is moving to hg, is this still wanted on the 1.9 branch?
![]() |
Reporter | |
Comment 10•17 years ago
|
||
After the switch, I don't care if it's on 1.9.0, but not sure if Axel would like to have it for e.g. easing Firefox localizers' work.
Assignee | ||
Comment 11•17 years ago
|
||
Yes, we should take this for fx3.0.x localizations. The line ending stuff discovered other bugs.
Assignee | ||
Comment 12•17 years ago
|
||
Actually, drop the rationale.
The rationale is really that I hope to land other patches to config which may very well touch Preprocessor.py, and it'd be good to have that tool on par with mozilla-central to reduce the risk in merges.
Comment 13•17 years ago
|
||
Comment on attachment 322570 [details] [diff] [review]
use universal line ending io and replace lineending, don't add
Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #322570 -
Flags: approval1.9.0.2? → approval1.9.0.2+
Updated•16 years ago
|
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•