Xavier de Gaye added the comment:
Thanks for reviewing the patch Martin.
> Why do you remove the code that loops over Modules/Setup? Maybe is it
> redundant with the other code for removing the already-built-in modules?
Yes because this is redundant, maybe not the case when this was written 15
years ago.
> The logic matching MODOBJS doesn’t look super robust.
Agreed on both points.
> if you added Modules/Setup.config to the list of Setup files to process,
> would that eliminate the need to look at both MODOBJS and
> sys.builtin_module_names?
The processing of the Setup files done by setup.py is not robust either. It
does not handle the lines of the form '<name> = <value>'. The syntax described
in Setup.dist allows for:
mod_form1 mod_form2 _mod_source.c
where both the 'mod_form1' and 'mod_form2' modules depend on the same source
file and one would like to build them statically. makesetup handles that case
while setup.py does not.
There is no guarantee that a change in the makesetup machinery would be
systematically reflected in a change to setup.py. And indeed this is the case
now - as you point it out - setup.py is currently missing the parsing of
Setup.config.
Here is a new patch that uses the result of the parsing done by makesetup in
setup.py.
----------
Added file: http://bugs.python.org/file45143/removed_modules_2.patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28444>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
