Show HN: A Modern C/C++ build tools (Simple, Fast, Cross-platform)

This tool is (again) just rehashing the same old build methods only with different syntax.

I'd really like to see a build tool that would take things to the next level.

- As a developer if I include "foobar.h" in my code, why do I have to workout the include paths myself? Why can't the build system search for the file and resolve the include paths? If there are any unresolvable ambiquieties then ask me.

- As a developer if I use for example std::thread why do I need to add manually -pthread to my build / linker flags. Why can't the build system do this for me?

- As a developer if I use let's say Win32 API in my code why do I have to manually add the linker libs and flags. Why can't the build system do this for me?

- As a developer if I use c++14 features in my code, why do I need to manually add the -std=c++14 whatever flag in my build files? Why can't the build system do this for me?

etc.

Everything else is just re-hashing the same old tiring build metdhologies with different syntax/problems/bugs/shortcomings/portability bugs.

I think Borland C++ did all the above in the 90s, having to manually tell GCC which libraries to link against (and with even in the "correct" order!) was something i found baffling back when i first tried MinGW.

Though it did help that all libraries and headers are part of the compiler itself. And perhaps it was using something like MSVC's #pragma comment(lib, "libname") (which i really wish GCC/Clang would implement at some point as it is very convenient) in every header it came with to properly associate with the relevant library, though i'm almost sure i replaced the OpenGL headers it came with and recreated the .lib file to be more complete (the default had only OpenGL 1.0 symbols) yet it still found the new stuff.

xmake can also support to generatr other project file. e.g. makefile vsproj cmakelist compile_command and etc.

  xmake project -k makefile
  xmake project -k vs2019
  xmake project -k cmakelist
  xmake project -k vsxmake 
  ...

> Now image you had this incredible build tool that produced X without any programmer doing any build related work ever at all. Your build output is X and value is V. 100% of your developer effort can go towards working on X and increasing V!

That is only the case for the simplest of software though. "Build systems" are often much more than just build systems: they are project management tools.

e.g. quite often I have to perform some preprocessing or code generation.

I could :

- A: write a $cross_platform_scripting_language script and integrate it to my build system & CI, ensure that the script interpreter is correctly found, that the build dependency graph is correct, etc etc. But just getting the same version of python to work reliably on 5+ different platforms is already quite a pain.

- B: write the preprocessor directly in my build system language (in my case, most of the time CMake).

Option B takes wayyyyy less time in my experience than option A, even though it looks more "build-related" than option A.

I got off the C/C++ roller coaster long time ago. Currently staying on D. Others get off at the Rust station. I don't intend to ever go back unless forced by my employer.