| msg163124 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2012-06-18 21:37 |
| 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 |
|
|
| msg163131 - (view) |
Author: Justin Venus (Justin.Venus) |
Date: 2012-06-19 01:51 |
| 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. |
|
|
| msg163153 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-06-19 09:46 |
| > 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. |
|
|
| msg163167 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2012-06-19 14:15 |
| 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. |
|
|
| msg163171 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2012-06-19 14:37 |
| 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 |
|
|
| msg163172 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-06-19 14:39 |
| This should be fixed now. |
|
|
| msg163174 - (view) |
Author: Jesús Cea Avión (jcea) * |
Date: 2012-06-19 14:54 |
| 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. |
|
|
| msg163175 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-06-19 15:00 |
| > 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. |
|
|