The devguide advise to run `make -j`, why not, but in any cases between `make -j4` and `make -j` the warning:

    -----------------------------------------------
    Modules/Setup.dist is newer than Modules/Setup;
    check to make sure you have all the updates you
    need in your Modules/Setup file.
    Usually, copying Modules/Setup.dist to Modules/Setup will work.
    -----------------------------------------------

is invisible (gets on screen first, and get kicked real quick by the compilation lines).

This got me once, and I'm not alone: https://bugs.python.org/issue32335 (And I suspect we're more than just two).

I propose to make this stop the compilation, proposing two cases:

- You modified the file? Touch it so it gets seen as up to date by makefile
- You didn't modified it? Copy Modules/Setup.dist to Modules/Setup

Something like:

    $ make
    -----------------------------------------------
    Modules/Setup.dist is newer than Modules/Setup;
    check to make sure you have all the updates you
    need in your Modules/Setup file.
    Usually, copying Modules/Setup.dist to Modules/Setup will work.
    Or if you want to keep your modifications, touch Modules/Setup
    to skip this warning.
    -----------------------------------------------
    Makefile:703: recipe for target 'Modules/Setup' failed
    make: *** [Modules/Setup] Error 1

I'd really like it if we could get rid of the Setup/Setup.dist thing.  It's a distraction to have to type `cp -f Modules/Setup.dist Modules/Setup` from time to time... even though I have never customized the Setup file.

On Dec 26, 2017, at 18:17, Antoine Pitrou <[email protected]> wrote:
> 
> I'd really like it if we could get rid of the Setup/Setup.dist thing.  It's a distraction to have to type `cp -f Modules/Setup.dist Modules/Setup` from time to time... even though I have never customized the Setup file.

+1 - do you have any thoughts on that?

Antoine: I may take a look at this too.

Still, stopping in the Makefile looks a first trivial step toward not being screwed by it, removing it looks non trivial, will raise discussions, let's make it another issue?

> +1 - do you have any thoughts on that?

I think the current scheme may have been useful at a time where DVCS didn't exist.  You would maintain an unversioned copy of Modules/Setup.dist in your work-tree.  Nowadays you can fork a github repo and maintain your own branch with changes to a tracked file.  I don't think Modules/Setup deserves special treatment compared to, say, setup.py or Makefile.pre.in.

> maintain your own branch with changes to a tracked file

Make sense for me, Xavier, would this fit your usage?

On 27.12.2017 00:24, Antoine Pitrou wrote:
> 
> Antoine Pitrou <[email protected]> added the comment:
> 
>> +1 - do you have any thoughts on that?
> 
> I think the current scheme may have been useful at a time where DVCS didn't exist.  You would maintain an unversioned copy of Modules/Setup.dist in your work-tree.  Nowadays you can fork a github repo and maintain your own branch with changes to a tracked file.  I don't think Modules/Setup deserves special treatment compared to, say, setup.py or Makefile.pre.in.

The file is mostly meant for people using tar balls rather than
checkouts to give them an easy way back to default settings
after making changes to the Modules/Setup file.

The same could be had by having Makefile.pre.in generate Setup.dist
from Setup while booting into build mode, avoiding the need to
sometimes create Modules/Setup manually.

It seems that it is possible to keep the current behavior for those that want to customize the configuration of Modules/Setup.dist (knowing that they can just use Modules/Setup.local if they are only doing additions to the Setup configuration) and at the same time get rid of these warnings for those that never change Modules/Setup.dist. This could be done this way:

* 'configure' does not create anymore Modules/Setup.
* The 'Makefile' target of the Makefile uses now Modules/Setup.dist when Modules/Setup is missing.
* A developer that wants to customize Modules/Setup.dist needs to copy (only once) manually Modules/Setup.dist to Modules/Setup and to modify this last file accordingly. She/he gets then the same warnings as those that are occuring currently and in that case it is useful to have the build abort upon such warnings as proposed in the current issue.

If this proposal is acceptable then it should be implemented in another issue, I think.

Discussion about further simplifications goes here: https://bugs.python.org/issue32430

I'm ok with turning the warning into an error. Does anyone object here?

> I'm ok with turning the warning into an error. Does anyone object here?

Please don't convert the warning to an error. Usually, I ignore the warning and "make" produces a working ./python binary anyway.

It's common that I get the warning when using git bisect, since it updates Modules/Setup.dist.

If you want to make it an error, I would prefer to have an option to "ignore the warning", like always copy Modules/Setup.dist to Modules/Setup (if it's detected as outdated).

I like Xavier's proposal (msg309078): only create Modules/Setup if you want to customize it, otherwise use Modules/Setup.dist. I *never* modified Modules/Setup, I don't even know its purpose, whereas it bugs me frequently with it's annoying warning...

It seems like I would prefer to see bpo-32430 fixed.

Fixed in 961d54c5c1916c09883ebcf7191babc969e5a5cf.