Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

amaanq
Copy link
Member

@amaanq amaanq commented Mar 12, 2024

This allows users to build parsers without having to run test or parse to invoke the compilation process, and allows them to output the object file to wherever they like. The build-wasm command was merged into this by just specifying the --wasm flag.

@amaanq amaanq force-pushed the build-cmd branch 5 times, most recently from 671e588 to 16d2bc9 Compare March 13, 2024 04:52
@maxbrunsfeld
Copy link
Contributor

Nice, this is great.

@amaanq amaanq force-pushed the build-cmd branch 2 times, most recently from e55cda2 to a9eea46 Compare March 13, 2024 06:44

You can specify where to output the shared object file (native or WASM) with the `--output`/`-o` flag, which accepts either an absolute path or relative path. Note that if you don't supply this flag, the CLI will attempt to figure out what the language name is based on the parent directory (so building in `tree-sitter-javascript` will resolve to `javascript`) to use for the output file. If it can't figure it out, it will default to `parser`, thus generating `parser.so` or `parser.wasm` in the current working directory.

Lastly, you can also specify a path to the actual grammar directory, in case you are not currently in one. This is done by providing a path as the first *positional* argument.
Copy link
Member

Choose a reason for hiding this comment

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

Can this be a list of paths? It'd be nice to be able to build multi-language parsers in one go.

Copy link
Member Author

Choose a reason for hiding this comment

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

how would this work with -o?

Copy link
Member

Choose a reason for hiding this comment

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

Good question. 🤔

cli/src/main.rs Outdated Show resolved Hide resolved
cli/src/main.rs Outdated Show resolved Hide resolved
@clason
Copy link
Contributor

clason commented Mar 14, 2024

Is there a support matrix for cc-rust (platforms, compilers) we can link to?

(Would be nice to have something similar for the make support of individual parsers.)

@amaanq
Copy link
Member Author

amaanq commented Mar 16, 2024

Is there a support matrix for cc-rust (platforms, compilers) we can link to?

(Would be nice to have something similar for the make support of individual parsers.)

Not exactly, though this would be nice. All I've found is this https://docs.rs/cc/latest/cc/#compile-time-requirements

@amaanq amaanq force-pushed the build-cmd branch 2 times, most recently from 9dbdaba to ba50037 Compare March 16, 2024 05:19
This allows users to build parsers without having to run `test` or
`parse` to invoke the compilation process, and allows them to output the
object file to wherever they like. The `build-wasm` command was merged
into this by just specifying the `--wasm` flag.
@amaanq amaanq merged commit e8dbe01 into tree-sitter:master Mar 17, 2024
@sogaiu
Copy link
Collaborator

sogaiu commented Mar 19, 2024

The build-wasm command was merged into this by just specifying the --wasm flag.

It seems by "merged" what was meant was that the build-wasm subcommand got replaced. Is that an appropriate interpretation?

Assuming so...

Is it possible to keep the old subcommand method of invocation available [1]? There are likely scripts and documentation that reference build-wasm. I saw one report for a script breaking and I know I have two repositories that depend on it, in addition to having documentation that mentions 'build-wasm'.

For reference, I believe the playground subcommand used to be called web-ui and there was a period when both were usable. I don't know why it was necessary to remove web-ui eventually, but this at least gave folks some time to notice and transition.


[1] So the old invocation method might use the new code underneath?

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.

5 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.