Skip to content
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

Outdated Modules/Setup warning is invisible #76610

Closed
JulienPalard opened this issue Dec 26, 2017 · 12 comments
Closed

Outdated Modules/Setup warning is invisible #76610

JulienPalard opened this issue Dec 26, 2017 · 12 comments
Assignees
Labels
3.7 (EOL) end of life build The build process and cross-build type-feature A feature request or enhancement

Comments

@JulienPalard
Copy link
Member

BPO 32429
Nosy @malemburg, @warsaw, @pitrou, @vstinner, @benjaminp, @xdegaye, @JulienPalard
PRs
  • bpo-32429: Abort compilation on outdated Modules/Setup file. #5015
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/JulienPalard'
    closed_at = <Date 2018-11-14.15:20:47.168>
    created_at = <Date 2017-12-26.22:10:38.639>
    labels = ['type-feature', '3.7', 'build']
    title = 'Outdated Modules/Setup warning is invisible'
    updated_at = <Date 2018-11-14.15:20:47.167>
    user = 'https://github.com/JulienPalard'

    bugs.python.org fields:

    activity = <Date 2018-11-14.15:20:47.167>
    actor = 'mdk'
    assignee = 'mdk'
    closed = True
    closed_date = <Date 2018-11-14.15:20:47.168>
    closer = 'mdk'
    components = ['Build']
    creation = <Date 2017-12-26.22:10:38.639>
    creator = 'mdk'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 32429
    keywords = ['patch']
    message_count = 12.0
    messages = ['309066', '309068', '309069', '309070', '309072', '309073', '309077', '309078', '309080', '309177', '310311', '329911']
    nosy_count = 7.0
    nosy_names = ['lemburg', 'barry', 'pitrou', 'vstinner', 'benjamin.peterson', 'xdegaye', 'mdk']
    pr_nums = ['5015']
    priority = 'low'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue32429'
    versions = ['Python 2.7', 'Python 3.6', 'Python 3.7']

    @JulienPalard
    Copy link
    Member Author

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

    \-----------------------------------------------
    [Modules/Setup.dist](https://github.com/python/cpython/blob/main/Modules/Setup.dist) is newer than [Modules/Setup](https://github.com/python/cpython/blob/main/Modules/Setup);
    check to make sure you have all the updates you
    need in your [Modules/Setup](https://github.com/python/cpython/blob/main/Modules/Setup) file.
    Usually, copying [Modules/Setup.dist](https://github.com/python/cpython/blob/main/Modules/Setup.dist) to [Modules/Setup](https://github.com/python/cpython/blob/main/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:

    Something like:

        $ make
        

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

    @JulienPalard JulienPalard added the 3.7 (EOL) end of life label Dec 26, 2017
    @JulienPalard JulienPalard self-assigned this Dec 26, 2017
    @JulienPalard JulienPalard added build The build process and cross-build type-feature A feature request or enhancement labels Dec 26, 2017
    @pitrou
    Copy link
    Member

    pitrou commented Dec 26, 2017

    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](https://github.com/python/cpython/blob/main/Modules/Setup.dist) [Modules/Setup](https://github.com/python/cpython/blob/main/Modules/Setup) from time to time... even though I have never customized the Setup file.

    @warsaw
    Copy link
    Member

    warsaw commented Dec 26, 2017

    On Dec 26, 2017, at 18:17, Antoine Pitrou report@bugs.python.org 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](https://github.com/python/cpython/blob/main/Modules/Setup.dist) [Modules/Setup](https://github.com/python/cpython/blob/main/Modules/Setup) from time to time... even though I have never customized the Setup file.

    +1 - do you have any thoughts on that?

    @JulienPalard
    Copy link
    Member Author

    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?

    @pitrou
    Copy link
    Member

    pitrou commented Dec 26, 2017

    +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.

    @JulienPalard
    Copy link
    Member Author

    maintain your own branch with changes to a tracked file

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

    @malemburg
    Copy link
    Member

    On 27.12.2017 00:24, Antoine Pitrou wrote:

    Antoine Pitrou <pitrou@free.fr> 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.

    @xdegaye
    Copy link
    Mannequin

    xdegaye mannequin commented Dec 27, 2017

    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.

    @JulienPalard
    Copy link
    Member Author

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

    @pitrou
    Copy link
    Member

    pitrou commented Dec 29, 2017

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

    @vstinner
    Copy link
    Member

    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.

    @JulienPalard
    Copy link
    Member Author

    Fixed in 961d54c.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.7 (EOL) end of life build The build process and cross-build type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants