Apply bacon to other languages and compilation backends ?

[Canop]

Some parts of bacon were designed for Rust and are tied to cargo:

• default bacon.toml file
• compiler output parsing
• test output parsing
• documentation
• the use of TOML (which is just totally unknown outside the Rust ecosystem)

That's not much. Bacon could be used for other build chains.

But as I don't currently have a personal need, I'll progress there only if there's some interest.
Comment if you're interested.

[TyberiusPrime]

Python is also adopting TOML these days.

[aragonnetje6]

so for basic functionality, i think it'd be best to basically have modular, replaceable parsing strategies for different compilers/tools, perhaps even formatters, selectable per job in the TOML file?. personally i'd have a usecase for python's mypy, black, and unittest/pytest, as well as haskell's GHC, so i could get started on those after factoring out the rust-specific logic

[detly]

As a note, I think you could add support for Ninja and get out-of-the-box support for the vast majority of C and C++ projects.

[Kludex]

I'm interested in this for Python. I maintain a popular web server https://github.com/encode/uvicorn, and I'd be interested in exploring how it would interact with it.

[Canop]

@Kludex Discussing such interaction might be hard to do in this issue. Maybe come to Miaou ?

[Canop]

There's progress on this topic: bacon 3.0 internally comes with a rough "framework" defining analyzers, which could be program/language specific. This is currently used to analyze nextest's output.

[Canop]

Another step: #256

[Canop]

Roadmap: https://dystroy.org/blog/bacon-everything-roadmap/

[tyilo]

Biome support would be nice :)

[Canop]

@tyilo can you check #271 ?

[tyilo]

That was fast :)

ruff support would also be great

[Canop]

@tyilo can you check #273 ?

[tyilo]

This blog post should probably be linked here: https://dystroy.org/blog/are-they-bacon-yet/

@Canop maybe add the link to the original issue description?