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

Add tools/emcoverage.py to obtain coverage information #9166

Merged
merged 9 commits into from
Aug 15, 2019

Conversation

quantum5
Copy link
Member

@quantum5 quantum5 commented Aug 7, 2019

This tool will allow us to find exactly what code is not run when using wasm backend, for example, to aid us in removing fastcomp code.

@quantum5 quantum5 requested review from kripken, sbc100 and tlively August 7, 2019 00:11
@sbc100
Copy link
Collaborator

sbc100 commented Aug 7, 2019

I'm ok with python3 here.. it can be seen as part of our move away from python2: #7198

sbc100 added a commit that referenced this pull request Aug 7, 2019
While reviewing #9166 I noticed that support a PYTHON key in the config
file but this doesn't effect any of the entry point (on UNIX the entry
points are defined by the #! line, on windows they are are defined as
`python` in the bat files.  So really this was only effecting python
sub-processes not the compiler itself.  This feature doesn't seem like
its useful, and also has no tests, so removing it for now.

However for the benefit of #9166 add support for setting this via the
`EM_PYTHON` environment variable.
sbc100 added a commit that referenced this pull request Aug 8, 2019
While reviewing #9166 I noticed that support a PYTHON key in the config
file but this doesn't effect any of the entry point (on UNIX the entry
points are defined by the #! line, on windows they are are defined as
`python` in the bat files.  So really this was only effecting python
sub-processes not the compiler itself.  This feature doesn't seem like
its useful, and also has no tests, so removing it for now.

However for the benefit of #9166 add support for setting this via the
`EM_PYTHON` environment variable.
@quantum5 quantum5 requested review from tlively and sbc100 August 13, 2019 22:48
@quantum5 quantum5 requested a review from tlively August 15, 2019 19:52
@quantum5 quantum5 merged commit 723b4bc into emscripten-core:incoming Aug 15, 2019
sbc100 added a commit that referenced this pull request May 20, 2020
It doesn't make sense for emscripten to be running under one python
version and then launch sub-processes under a different one.

I had thought that emsdk used this it sets EMSDK_PYTHON which can be
used to launch emscripten, but once launched we want to continue to use
the version of python we started out with.

I first added support for this in #9175 supposedly for the benefit
of #9166, but that change didn't end up using it anyway.
sbc100 added a commit that referenced this pull request May 21, 2020
It doesn't make sense for emscripten to be running under one python
version and then launch sub-processes under a different one.

I had thought that emsdk used this but it sets EMSDK_PYTHON which can
be used to launch emscripten, but once launched we want to continue to use
the version of python we started out with.

I first added support for this in #9175 supposedly for the benefit
of #9166, but that change didn't end up using it anyway.
belraquib pushed a commit to belraquib/emscripten that referenced this pull request Dec 23, 2020
While reviewing emscripten-core#9166 I noticed that support a PYTHON key in the config
file but this doesn't effect any of the entry point (on UNIX the entry
points are defined by the #! line, on windows they are are defined as
`python` in the bat files.  So really this was only effecting python
sub-processes not the compiler itself.  This feature doesn't seem like
its useful, and also has no tests, so removing it for now.

However for the benefit of emscripten-core#9166 add support for setting this via the
`EM_PYTHON` environment variable.
belraquib pushed a commit to belraquib/emscripten that referenced this pull request Dec 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants