This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Build/test artifacts not ignored for framework build
Type: behavior Stage:
Components: macOS Versions:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: barry, jaraco, ned.deily, ronaldoussoren
Priority: normal Keywords:

Created on 2019-05-25 13:58 by jaraco, last changed 2022-04-11 14:59 by admin.

Messages (2)
msg343479 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2019-05-25 13:58
When developing on macOS, after some build/test operations (I'm not sure exactly which, but seemingly relating to a framework build), artifacts are generated which aren't ignored. As a result, it's easy for them to leak into a merge request as they did with GH-12547 (issue34632).

For example:

```
cpython master $ ./configure --enable-framework=/Users/jaraco/Library/Frameworks && make
...
cpython master $ git status                                                                                                                                                    
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        Mac/Resources/app/Info.plist
        Mac/Resources/framework/Info.plist
        Python.framework/Python
        Python.framework/Versions/

nothing added to commit but untracked files present (use "git add" to track)
```

(also Python.framework/Resources/, except that's in the repo at the moment, the reason for reporting this issue)

Is there not a reason to ignore these artifacts so they don't risk being added to the commit?
msg343509 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-05-25 20:50
That seems like a reasonable request.  We should also check that the Makfile clean* rules do the right thing.  One potential complication: the framework name is specified by the ./configure --with-framework-name= parameter, so it may not always be "Python.framework", the default value.
History
Date User Action Args
2022-04-11 14:59:15adminsetgithub: 81225
2019-05-25 20:50:27ned.deilysetmessages: + msg343509
2019-05-25 17:53:10barrysetnosy: + barry
2019-05-25 13:58:32jaracocreate