homepage

The Solaris compiler chokes on the embedded NUL character. Perhaps we can find another way to remove the importlib.h diffs from the notification e-mails (simply hardcode the filename?).
http://www.python.org/dev/buildbot/all/builders/x86%20Solaris%2011%203.x/builds/21/steps/compile/logs/stdio
/opt/solarisstudio/bin/cc -c -O -I. -I./Include -DPy_BUILD_CORE -o Python/frozen.o Python/frozen.c
"Python/importlib.h", line 3847: null character in input
cc: acomp failed for Python/frozen.c 

What is the purpose of the comment at the end of "Python/importlib.h"? If I remove the comment that states "binary marker for mercurial" (something to that effect anyhow) the code compiles and only the tests fail.

> What is the purpose of the comment at the end of "Python/importlib.h"?
The purpose is to include a NUL character in the source file so that Mercurial treats this (generated) file as a binary file, and so that the diffs are omitted in commit notification e-mails.
Since this does not seem to ve valid C (or is it?), we will have to find something else, I think.

It looks as great disadvantage compared with Subversion.
There are several ways to solve this problem:
1. Python/freeze_importlib.py generates a raw binary file Python/importlib.dump (just marshal dump) and this file is placed in the repository. Then a small C program Python/unpack_importlib.c (or something of the sort) is compiled and converts the file Python/importlib.dump in the file Python/importlib.h.
2. Python/freeze_importlib.py generates a header file Python/importlib.h.in with binary marker as now and this binary file is placed in the repository. Then on Posix systems Python/importlib.h.in is converted to Python/importlib.h by deleting binary marker (tr -d '0円') or whole line with binary marker (head/tail/sed/grep/awk). On Windows Python/importlib.h.in is just copied to Python/importlib.h.

New changeset 7d86e207598f by Antoine Pitrou in branch 'default':
Issue #15103: remove the NUL character (serving as a Mercurial binary marker) from Python/importlib.h.
http://hg.python.org/cpython/rev/7d86e207598f 

This should be fixed now.

As a general rule, generated files should not be included in the repository.
Recent mercurial versions include a "--large" parameter for "hg add" that threat files as binary. In particular, precludes "hg diff", that I guess it is the point here.

> As a general rule, generated files should not be included in the
> repository.
We already include generated files such as configure. This is either for
convenience or for bootstrap purposes.
> Recent mercurial versions include a "--large" parameter for "hg add"
> that threat files as binary.
No, it has nothing to do. "--large" is added by the largefiles
extension.