-
Notifications
You must be signed in to change notification settings - Fork 90
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
Build System Rework #4 #236
Comments
I’m newish. But it took me a bit to figure out what data/files are relevant for the project. For most c projects all the relevant files are placed along side the src for the project. I think I’d rather have a folder init script for my particular micro family. But then again, the current method allows switching between things |
Idea: We can ship MicroZig as a monolith, but not as a mono-package. We did the split originally to reduce package size, and this is still a concern. But with the introduction of lazy dependencies, we can now make a single package the user can pull in, and we can then have an inner resolution logic pulling in all the BSPs lazily. This will decrease download and cache size, and gives the user a monolithic frontend, which might improve UX a good bunch Only question is how to distribute the information about BSPs... This might require some "build logic" that glues together the BSPs into a singular data structure... const BSPs = struct {
avr: ?type = null,
rp2: ?type = null,
stm32: ?type = null,
…
}; which would be populated lazily with the |
Really only three pain points with MicroZig's build system in order of most to least painful:
.dependencies = .{
.@"microzig/build" = .{ .path = "../../../build" },
.@"microzig/bsp/raspberrypi/rp2040" = .{ .path = "../../../bsp/raspberrypi/rp2040" },
}, In your .dependencies = .{
.microzig= .{ path, url, whatever},
}, be the only requirement for including MicroZig in your project, build utilities and all! I think I already have a loose understanding of what prevents us from doing this in Zig's current build system, but I'll spend some time brainstorming.
@ikskuh would your idea basically be accomplishing number 1 in my list? I like the idea of leaning on lazy dependencies to only use what the user wants especially if it allows us to only import a single package to use MicroZig! |
Oh! Sorry, one more thing that's pretty important to me. MicroZig should support a "native" target (Linux, Windows, etc.). Obviously HAL/device code isn't included in this, it just gives you the bones to make it easy to run certain parts (think testing) or all of your "business logic" code natively. I have a complicated build setup on my current projects in C/C++ that lets me do this and it's a dream once you get it working. You basically always have a dummy, simulation version of your firmware that runs on your computer. I'll take on brainstorming how to do this, since I currently haven't even done this vanilla in Zig's build system. I think Zig's build system and language is very well suited for this purpose though. Lazy evaluation + easy comptime switching based on architecture should make this much more ergonomic than C/C++ + CMake. |
Yes, that would be addresses by the "entrypoint/mono-package" style package. No idea how we could make that yet, but it should be doable for sure. We just need to keep the vendor packages in sync with the root build script, but that's totally fine i guess
I'm in for that, i don't like "bsp" either. We could also use
I agree, it's super useful for testing and simulation, which makes it easier to run improved tests |
Yep I think once I get RP2350 in a somewhat working order I may take a break from that to noodle on the build system. It makes my head hurt every time but there should be a way to get what we're after and ditch the need to patch all of the relative imports into URLs... Well, hopefully :) |
I was thinking that using git submodules might help with the zig zon archives, and allow keeping somewhat the same monorepo. Sadly they are a pain. |
Nah, not really, as you then have to double-maintain all dependencies, while |
I was thinking about the people who are working off of main. They have an additional steps downloading extracting the repo and placing somewhere convenient. But basically it’s because “.url” doesn’t support a relative path on zon. I feel that this could be potentially fixed by using CI to build the individual root packages (artifacts). It would help with release consistency, cause individual revs could be used. |
I'm liking what I'm seeing, to summarize some action items:
For the single entry point, I think that's what we need, we just need to figure out a way to make it work with lazy dependencies, so we need some sort of runtime registration. Now another question for y'all, up until now I've been big on users being able to set up their own hardware support if they didn't want to deal with upstreaming it. But I'm starting to question that, why put work into that part of the design for people who aren't going to give back to the project? Like maybe we still expose that ability, only if it's trivial to do so. What do you think? For the native target, I know @vesim987 wants it so that he can leverage the GPIO interface on a raspberry pi. Is what you're referring to @haydenridd more about software simulation where I imagine you provide some fake hardware? (I suppose vesim could wire the gpio interface to his OS). |
Yup exactly, for the dev phase where you're still waiting for boards to come back but just want to test your business logic. Essentially just give you an easy way to compile a native executable. Obviously it's up to the user to correctly swap out their |
I would use
For the GitHub record, I started drafting a new build interface here: My current focus is on composing via |
The build system is centered almost completely around the build/build.zig file. This I think cuts off a lot of flexibility in terms of what it is capable of. This, for instance, is very hard to achieve.
I suppose a better way to write the build system would be to have each part ( An issue that I can spot in this way of doing things is that there could be some code repetition in each build.zig (in all chips for instance as we compile the registers). But I don't think this is a significant issue. What do you think? I'll be glad to implement this, but I thought it would be better to ask before, so as to not work in vane. |
I also think this would improve a little the readability of the repo. It took me quite some time to learn how things are glued together. |
@mattnite sees reason to rework the build system once again.
I think we're not in a perfect place yet, so that's reasonable.
What are features we need and what are features we want to have?
The text was updated successfully, but these errors were encountered: