Branko Čibej wrote on Fri, Feb 13, 2015 at 14:34:55 +0100:
> On 13.02.2015 11:25, Daniel Shahaf wrote:
> > +++ build/generator/gen_base.py (working copy)
> > @@ -248,12 +248,12 @@
> > try:
> > - old_contents = open(fname, 'rb').read()
> > + old_contents = open(fname, 'r').read()
> > except IOError:
> > old_contents = None
> > if old_contents != new_contents:
> > - open(fname, 'wb').write(new_contents)
> > + open(fname, 'w').write(new_contents)
> > print("Wrote: %s" % fname)
>
> I don't understand this change. We read and write the files in binary
> mode because we don't want to bother with encoding conversions.
> Incidentally, this removes the ability to generate makefiles on Windows,
> because it will write them with \r\n line endings that make doesn't like.
>
> Is it a problem with the str()/unicode()/bytes() incompatibility? If it
> is, the ezt template generator will have fun with those, too; even
> though we shouldn't have any non-ASCII characters in the templates, nor
> in the generated makefiles or .vc(x)proj files.
>
Yes, it's str/bytes madness. The contents of errorcode.inc is
constructed as an str and passed to write_file_if_changed(new_contents=...)
as an str, resulting in the following error:
TypeError: 'str' does not support the buffer interface
This function has two other callsites. One of them is in an 'if 0'
block. The other is Windows' write_with_template(), which I believe
will also pass an str, since it calls ezt, which opens the file as
follows:
self.text = open(fname, 'rb').read()
if sys.version_info[0] >= 3:
# Python >=3.0
self.text = self.text.decode()
So, I'll go ahead and mimic ezt's solution. That won't affect Python 2
users at all.
I'll implement the other changes you suggested and commit. Thanks both
of you for the reviews,
Daniel
