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

[cmpcodesize][1] Extract otool subprocess calls #636

Closed
wants to merge 1 commit into from

Conversation

modocache
Copy link
Contributor

What's in this pull request?

The functions in cmpcodesize.compare do several things: they call otool, they use regex matchers to extract information from otool's output, and they output that information using print().

Currently, the only way to test cmpcodesize is via functional tests: ones that actually run on a dylib like libswiftCore.dylib. This takes a lot of time and is difficult to fully automate.

The commit in this pull request extracts otool calls from cmpcodesize.compare. It also adds tests for those calls.

Future commits can test the functions in cmpcodesize.compare using canned strings, instead of actual otool output.

Why merge this pull request?

  • It makes cmpcodesize.compare more modular, and eliminates all uses of the flatten() function.
  • It improves test coverage.
  • It makes it easier to start testing the rest of cmpcodesize. Instead of running functional tests* on a sample dylib, we can refactor it such that we pass cmpcodesize sample strings, and verify its behavior parsing those sample strings.

* I have some functional tests running locally. They verify the results of running cmpcodesize on a test fixture: libswiftCore.dylib. libswiftCore.dylib is 9 MB, so including it as a test fixture in source control may not be desirable.

What downsides are there to merging this pull request?

I suppose some could argue the tests in utils/cmpcodesize/tests/test_otool.py don't provide much value--they're testing some very simple logic.

The functions in `cmpcodesize.compare` do several things: they call
otool, they use regex matchers to extract information from otool's
output, and they output that information using `print()`.

Currently, the only way to test cmpcodesize is via functional tests:
ones that actually run on a dylib like libswiftCore.dylib. This takes a
lot of time and is difficult to fully automate.

By extracting otool calls from `cmpcodesize.compare`, we can test those
in isolation. Furthermore, future commits can test the functions in
`cmpcodesize.compare` using canned strings, instead of actual otool
output.
@modocache modocache changed the title [cmpcodesize] Extract otool subprocess calls [cmpcodesize][1] Extract otool subprocess calls Dec 18, 2015
@modocache
Copy link
Contributor Author

This should probably be reviewed by @eeckstein , @swiftix, and @nadavrot. 👋

@practicalswift
Copy link
Contributor

@modocache Should we take another look at those change - do you have time to resolve the conflicts? :-)

@modocache
Copy link
Contributor Author

I'd like to confirm this script is used at all first. If no one uses it I think it'd be better to delete than to maintain. @eeckstein, are you aware of anyone using this?

@eeckstein
Copy link
Contributor

The script is used a lot.

@modocache
Copy link
Contributor Author

Awesome! Yeah, I'll spruce up these PRs. Outputting CSV (SR-463) and reading ELF (SR-407) is also on my radar.

@eeckstein
Copy link
Contributor

Great! Thanks!

@modocache
Copy link
Contributor Author

Sorry for letting this languish. I don't think I have the capacity to shepherd this at the moment. I'll close this pull request to reduce the amount of noise on the repository. Thanks!

@modocache modocache closed this Sep 8, 2016
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