Halfix – A portable x86 emulator written in C99
github.com
github.com
Those screenshots must've taken some extreme patience. Especially that Windows 10 one. 70-100 MIPS is roughly a fast 486. It sounds like this isn't even a JIT, unlike QEMU's emulation mode, and the latter is already quite noticeably slower when running modern OSs on modern hardware.
> node makefile.js win32
Node.js now required to build a pure c project? I don’t want to live on this planet anymore…
It’s like jsonnet to me - if you need config files that make config files something has gone horribly wrong.
Then again, I stopped bothering trying to learn Cmake. If I see Cmake I don’t bother with the project so there’s that - and also not a fan of c++ so I am probably the wrong audience anyway.
cmake_minimum_required(VERSION 3.5)
add_executable(exe file.cpp)
exe: file.cpp
And if you argue that the barebones example is insufficient for a real project: absolutely true. The same applies to your cmake example.
Also I've actually checked that Makefile, and it errored out (macOS):
make: Nothing to be done for `exe'.https://www.gnu.org/software/make/manual/html_node/Catalogue...
As you can see, it takes flags and compiler from the environment.
file: file.cpp
Another issue is that indeed, CC+CFLAGS is supported by default (implicit) rules, but as soon as the user tries to build a custom rule (which is 99% of the time), the support is lost unless explicitly adding it.
Third issue is that it seems that implicit rules can be different by different implementations of make, i.e. BSD make can have different rules than GNU make. Even if we consider only one implementation, then default rules can be different to each platform. The docs state that the user should consider the output of the `make -p` command in order to see the rules, which gives me an impression that different implicit rules can exist on different Linux distros, depending on how `make` was compiled (not sure what is the de facto state).
I mean, it doesn't sound simple.
Trivial examples look nice enough in either system, big ones look bad in make and utterly fucked in cmake. Some of this is that people keep trying to write things in cmake scripts that should be external programs in a workable language.
Putting an equal sign between CMake and Make, because the complexity increases in both, is pretty ignorant IMO. It's like saying "A car is no better than a bicycle, because both have problems with tires when driving long enough".
You have pasted a link to a complicated build system, which would be impossible to write and maintain in manual Make. It would require using Autotools. But then the Windows support would be dead. And lots of the files from the directory you've pasted are there in order to interface with hard-to-interface autotools-based build systems.
You can check out libarchive, which has support for both Autotools and CMake: https://github.com/libarchive . I'm not saying it uses both build systems the best possible way, but I pick CMake build over Autotools any day. What I get for free?
- I can open the project in my favorite editor and I have clangd working automatically,
- I can open it in Visual Studio, CLion, Xcode, Eclipse, or whatever,
- I can create multiple configurations (release, debug, asan, clang, gcc, vs2019, vs2022), comple them all and run tests for all configs at the same time after each change,
- When changing the build system itself, I don't need to think in layers: first the M4 layer, then the bash layer (or was it sh?), then the /bin layer -- "is my option passed to "cp" accepted on OpenBSD or is it a GNU extension? I better quickly install an OpenBSD VM and check it."
By the way, implementing the logic in CMake instead of an external scripting language may be in order to decrease the dependencies of the build system itself. I mean, why should I require having to install Tcl in order to compile my Gtk Bitcoin-monitoring app? Also the argument with "should be implemented in scripting language" is an opinion, which is heavily discussed when talking about wheter a build system's language should be turing-complete, or shouldn't. There is no consensus in that discussion.
Last point, I'm not advocating the use of CMake the tool. I'm advocating the use of CMake the model. Meson uses a similar model, and if the world would switch to Meson instead of CMake, I would still be happy.
There is a lot to criticize about CMake, but this is just RTFM level silly.
I would like to work with your devops :)
Read the code. It literally reinvents all of GNU make...badly. Incl checking file dates to decide what to rebuild, implementing "clean", etc...
You may still argue that this project still requires GCC and thus there should be Make even in Windows. That's reasonable, but right now I have GCC and Clang but no Make in my Windows console. If you can remove a hard dependency on Make with a reasonable cost (and I don't claim it's the case with this project, I would have used Ninja instead [1]) it's pretty worthwhile in my opinion.
[1] See https://github.com/lifthrasiir/j40/blob/main/make.cmd and https://github.com/lifthrasiir/j40/tree/main/extra/build for example; with this setting `make` works both in the standard *nix and Windows.
I think that is a very good argument though: Windows doesn't have MSVC or any other compiler out of the box either, it is up to you to install the requirements so having Make as a requirement - especially considering how standard it is - is perfectly fine. Using something like MSYS2 gives you a Linux-like shell with all the tools you'd expect there.
There is no real reason to require Node aside from the author wanted to play around with it, the functionality that tool provides can be provided by other existing tools (Autotools, premake, CMake, meson/muon, etc) or even GNU Make itself (using its extensions that wont be compatible with other "makes" though).
(also while Autotools can feel a bit arcane, they have one feature that other similar tools do not have: you do not need to have Autotools installed to build the project, only some shell and some make, both being very standard in pretty much any unix-like OS and for Windows, well, see the first paragraph :-P)
sorry, what is the abomination here?
The idea that an x86 emulator, written in C99, would require node to build is a smell if I’ve ever smelled one.
If a dev can’t be bothered to use standard tooling, can he be bothered to write safe and performant C? Is this kind of “cleverness” running throughout his code? Maybe the build process is “too complicated” for standard tools, which is a problem for sure.
This is more of a question for the next developer who tries to pull something like this, I don’t really want the OP to be discouraged from continuing their work. Just, maybe next time, don’t force JavaScript into a round hole.
Tbh I'm kind of surprised they didn't use Gulp.
// Special build system used for Halfix builds. Supports the following features: // - All built object files go in build/objs (no cluttering src/) // - Build multiple targets at once (i.e. switch between Emscripten and native // builds without having to clean) // - Parallel build (same as make -j) // - Certain files can be conditionally built based on the target // - Dependency resolution and conditional compilation (note: this is a bit // buggy) // - Automatic dependency regeneration (via redep) // - Simple to use (no configuration, multi-platform, etc.) // Usage: // node makefile.js [target] [options] // Omit "target" for default native build. // Run with --help for options and target list.
> Why? I made this mostly for fun
Some people find C more fun to write than Rust or C++.
>> most of the modern code should be written in
It's for fun; "should" doesn't apply to projects written for fun.
It shouldn't apply to any project. We shouldn't accept the Rust astroturfers injecting themselves into every thread here. Rust has problems, too, and there are many better choices for many applications.