-
-
Notifications
You must be signed in to change notification settings - Fork 34.5k
bpo-32430: During 'configure', don't copy Setup.dist to Setup. #8260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| The 'configure' script no longer copies Modules/Setup.dist to Modules/Setup. | ||
| If Modules/Setup exists, it will be used in preference to Modules/Setup.dist | ||
| (this fallback logic is done by the Modules/makesetup script). Remove the | ||
| makefile rules to re-generate Makefile and Modules/config.c if Modules/Setup | ||
| or Modules/config.c.in changes. To re-generate, you must run "make | ||
| makesetup". Normally that is not required since 'configure' already runs | ||
| makesetup. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -98,11 +98,23 @@ CYGWIN*) if test $libdir = . | |
| esac | ||
|
|
||
| # Main loop | ||
| for i in ${*-Setup} | ||
| for setupfile in ${*-Setup} | ||
| do | ||
| case $i in | ||
| # Check if Setup file does not exist. In that case, use | ||
| # Setup.dist from libdir (source) folder. In the normal case, | ||
| # the user does not create or modify Setup and so Setup.dist | ||
| # from the source distribution is used as-is. | ||
| case $setupfile in | ||
| */Setup) | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This pattern matching on */Setup is a bit ugly. Because makesetup can be called with different arguments (not just from 'configure'), we have to handle running on different Setup files. Eons ago, makesetup + Setup would be used instead of setup.py for 3rd party extension modules. Now, I suspect 'makesetup' might only be used from within the cpython build. |
||
| if ! test -f $setupfile; then | ||
| setupfile=$libdir/Setup.dist | ||
| fi | ||
| ;; | ||
| esac | ||
|
|
||
| case $setupfile in | ||
| -n) echo '*noobjects*';; | ||
| *) echo '*doconfig*'; cat "$i";; | ||
| *) echo '*doconfig*'; cat "$setupfile";; | ||
| esac | ||
| done | | ||
| sed -e 's/[ ]*#.*//' -e '/^[ ]*$/d' | | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -18355,12 +18355,6 @@ $as_echo "$as_me: WARNING: unrecognized options: $ac_unrecognized_opts" >&2;} | |
| fi | ||
|
|
||
|
|
||
| echo "creating Modules/Setup" >&6 | ||
| if test ! -f Modules/Setup | ||
| then | ||
| cp $srcdir/Modules/Setup.dist Modules/Setup | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These few lines are the source of the 'evilness' with the current behavior, IMHO. Setup is created from Setup.dist but only on the first run of 'configure'. If you update your source tree using the VCS, Setup.dist could get updated but Setup becomes stale. Re-running 'configure' is not sufficient to fix it. You have to do a "make distclean" or something dramatic. |
||
| fi | ||
|
|
||
| echo "creating Modules/Setup.local" >&6 | ||
| if test ! -f Modules/Setup.local | ||
| then | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, perhaps this is not okay for the PC build? Since we don't copy Setup.dist to Setup, the check would fail without a change. We could look for Setup.local but looking for config.c makes more sense to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Talking to myself, ;-)]
It looks like this should be okay. The PC build has its own getpath.c file and so this change doesn't affect it. The purpose of this check (as I understand) is to find if we are running 'python' from within the build directory. So, we use a file that exists in the build directory (and if separate source and build directories are used, not in the source directory).