you _can_ just tell zig build to call make (std.Build.addSystemCommand, https://ziglang.org/documentation/0.16.0/std/#std.Build.addS...). the only benefits of an inbuilt make would be not having to install it and that it could maybe intercept calls to external compilers and replace them with `zig cc` or something similar but i get the impression that supporting nontrivial make scripts would be very hard
Efforts to pull out information from existing build systems (if possible, ofc) means that you don't have to spend your time _rewriting build scripts_.
I don't know if it's really possible. Maybe this is step .. 4 of 34 to getting there. Just wondering if there's an alternative here that doesn't involve rewriting build scripts
Maybe a part of the pitch here is to just upstream these build scripts so that ones makefile becomes "just" `zig build`? In that case I'd actually like to see (for example) a fork of oyacc using what is figured out in https://github.com/allyourcodebase/yacc to "just" use the build script even in the higher level project.
> so then my glib question: what is the purpose of this project?
The whole point is to massively simplify integrating those libraries into Zig projects by explicitly not having to deal with external build systems or separate C/C++ compiler toolchains.
> Is the grpc makefile no bueno?
Does it work out-of-the-box on Windows? That's usually the first question when encountering a Makefile (and just looking at the first lines of the Makefile, it doesn't, instead it needs to run inside mings: https://github.com/grpc/grpc/blob/a63b3a4d949a7057a0e5443e7a...).
With Zig you usually only need the Zig toolchain, which runs just fine in a regular Windows cmd.exe.
i do like zig and its build system, but i agree that i see little point to the allyourcodebase repositories. you can probably learn about what you _can_ do with the build system through them, but i don't think they're best practice. they just redefine the build graph either statically (harder to update) or through path generation with python or something of the sort (what's the point, it's not contained in the zig build system anymore). i also remember some repositories getting quite outdated, though it seems there's been more effort to keep them updated these days.
the one thing i will blame zig for here is the refusal to make some system to just include all of the files in a directory (hence allyourcodebase's python scripts). it makes sense with zig's import & module system but i think it would probably be a big blocker for some projects that they'd have to manually list out every single C file in their source.
you can currently use the filesystem apis to manually walk through files in your build script, though this is discouraged and will go away with upcoming change of isolating the build script
Yes, of course. I just wanted to say that I think these tools are very suitable for teaching programming to beginners in a very short time and with excellent feedback. There's no need to go to the margins.
in this same release Minecraft removed exclusive fullscreen on MacOS, i wonder why they haven't done the same on Windows & Linux - maybe people still have uses for that stuff on those operating systems? in my experience exclusive fullscreen is Awful on MacOS
> i wonder why they haven't done the same on Windows
Probably because a lot of people feel like they need exclusive fullscreen for best performance and/or latency. But in reality borderless fullscreen is exactly the same when games use the DXGI flip model. It bypasses DWM (the compositor) to render directly to the display when only the game is visible and seamlessly allows you to switch to other windows. You can even disable Vsync and it will allow screen tearing when bypassing DWM.
I highly doubt that macOS fullscreen has that much higher latency than Windows fullscreen. The latency is so fine that I play Windows games over a capture card using OBS as the monitor. (The Mac has a 120Hz display though.)
I like to play games like ARC Raiders using that setup. Works perfectly fine. Sure it sucks that I need Windows at all for it, but SteamOS isn't an option yet due to my 3090
I’m not talking about the latency, more of the interface surrounding it and the overall feel of it. It’s kind of hard to describe what I dislike about it.
I’m not really a fan of the way it’s a three finger swipe sideways to leave and enter the full screen either.
I’m pretty sure I have had at some point issues where putting my cursor at the top of the window erroneously shows the menu bar within certain types of games.
Not sure if I’m remembering right, it’s been a while since I’ve tried playing games on Mac.
What you're describing is Spaces which is macOS's multi-desktop system. I agree it's annoying to have to tolerate a glacial animation just to switch between apps when they happen to be fullscreen. It's not a deal-breaker for me, but it's definitely near the top of my list of annoying things about macOS. But fullscreen applications are on the same level as additional desktops, basically. My personal solution is just to get good at swiping quickly but there is also now an app that simulates the trackpad gesture well enough to get instant switching.
The menu bar is supposed to appear with the cursor at the top of the screen. I have also encountered issues where it doesn't properly hide until you bring your cursor back in order to take the cursor away again and then it hides. It's a quirk but I sort of understand why it happens and it's just a small glitch to me.
Perhaps I was playing an RTS or city builder game or something along those lines and experienced that problem with the menu bar, and maybe if that did happen the developer could have prevented it with a better port.
Does macOS even have exclusive fullscreen anymore? I haven’t looked into it, but my impression is that it fakes it with borderless windowed even when the app explicitly asks for it.
it does still exist as far as i understand it. the resolution you select affects the size of the mouse cursor and then when switching away from the game you can see the rest of the system resizing back to normal
Yes. On Apple Silicon Macs (w/ macOS Sonoma or later), native fullscreen automatically triggers Game Mode. This feature slashes input lag by prioritizing CPU/GPU resources and doubling the Bluetooth polling rate to 240 Hz for wireless accessories. Gaming works very well in this mode, even with PC titles played thru crossover.
Conversely, using borderless windowed mode instead of native fullscreen on macOS adds rendering latency due to the Desktop Window Manager (DWM) compositor. The latter is 'doing it wrong' and has the lag people don't like.
