Skip to content

Conversation

aheejin
Copy link
Member

@aheejin aheejin commented Sep 25, 2025

The 'paths' file should contain paths that match those of sources field in the source map, which can be hard to figure out because they can be relative to some build directory.

This adds --print-sources option, which prints the contents of the sources field. You can just manually open source map files to obtain the same information, but they are usually hard to read without any newlines. You also can use a general JSON prettyprinting tool, but I think it wouldn't hurt to provide the same info handy here.

The 'paths' file should contain paths that match those of `sources`
field in the source map, which can be hard to figure out because they
can be relative to some build directory.

This adds `--print-sources` option, which prints the contents of the
`sources` field. You can just manually open source map files to obtain
the same information, but they are usually hard to read without any
newlines. You also can use a general JSON prettyprinting tool, but I
think it wouldn't hurt to provide the same info handy here.
@aheejin aheejin requested a review from dschuff September 25, 2025 06:56
Comment on lines +77 to +78
parser.add_argument('wasm', nargs='?', help='Path to the input wasm file')
parser.add_argument('paths_file', nargs='?', help='Path to the input file containing paths')
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These became optional because when you use --print-sources these are not mandatory. (We manually check for their existence below when --print-sources is not given)

Copy link
Member

@dschuff dschuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. maybe another useful diagnostic functionality would be when actually doing a split, to print how many functions (and bytes of functions?) matched each split-module in the input patterns, which might tell you at a glance whether things worked approximately as expected.

@aheejin
Copy link
Member Author

aheejin commented Sep 25, 2025

Makes sense. maybe another useful diagnostic functionality would be when actually doing a split, to print how many functions (and bytes of functions?) matched each split-module in the input patterns, which might tell you at a glance whether things worked approximately as expected.

When -v is given we already print the {path: files} mapping. I've added the # of functions too: 61eeb49

@aheejin aheejin merged commit bce7571 into emscripten-core:main Sep 26, 2025
32 checks passed
@aheejin aheejin deleted the empath_split_print_sources branch September 26, 2025 03:03
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.

2 participants