Skip to content

Conversation

@Nextness
Copy link

@Nextness Nextness commented Aug 6, 2025

Hello Mr Tsoding. Hopefully you find this PR somewhat relevant. It contains my perspective on how we could migrate from Makefiles to Crust for the build system.

This initial commit has the basic idea of generating the object files and b itself, without flags. Before committing strongly to any architecture and possibly wasting time, I would like to know your input.

Here are some additional considerations:

  1. The inclusion of build.rs at the root may not be the greatest, specially with #[path = "./src/crust.rs"], but it technically works.
  2. Makefile as the bootstrap for bbuild, and then all subsequent compilations using it.
  3. Flags that I feel are useful when we using bbuild. There is an exponential number of flags that I can think of, but for the sake of this initial conversation I will keep it simple and similar to what is in the Makefile.
    1. bbuild --all: builds everything.
    2. bbuild --test: builds tests.
    3. bbuild --os-target <some_os>: obviously targets the os. The default should always be the current os.
    4. bbuild --back-end <some_back_end>: selects the backend. The default should be the one available in the PC.

Side note: Please disregard "os_target". This is not the best approach and I'm aware.

@rexim
Copy link
Member

rexim commented Aug 6, 2025

No, this is not how I wanted to do it. My idea was to keep extending bgen.rs until it just does 90% of the build, since it wants to go in that direction anyway.

@rexim rexim closed this Aug 6, 2025
@nullnominal
Copy link
Contributor

why not copy this PR into bgen.rs

@Nextness
Copy link
Author

Nextness commented Aug 9, 2025

I could implement something for bgen, but then it would be different. This PR had the objective to replace makefile. As far as I understood, Tsoding will keep it for now. What makes more sense is to move testing to bgen as described in here #281. I can work on that and move some of the structure I build.

However, I think there is more work than "just" moving to bgen, since having tests as part of the backend that people can select, requires some thought. Should there be a default tests suite that b expects, and the backends must implement? Should the backend have complete ownership of what to test? Should we have both?

@nullnominal
Copy link
Contributor

I could implement something for bgen, but then it would be different. This PR had the objective to replace makefile. As far as I understood, Tsoding will keep it for now. What makes more sense is to move testing to bgen as described in here #281. I can work on that and move some of the structure I build.

However, I think there is more work than "just" moving to bgen, since having tests as part of the backend that people can select, requires some thought. Should there be a default tests suite that b expects, and the backends must implement? Should the backend have complete ownership of what to test? Should we have both?

we should probably have both styles.
One test suite is for the IR, and a couple of test suites for the backends

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