Show HN: Xmake, a modern C/C++ build utility

Thanks for trying to improve the ecosystem around native code building tools. I appreciate it a lot.

    add_requires("libuv master", "ffmpeg", "zlib 1.20.*")
    add_requires("tbox >1.6.1", {optional = true, debug = true})
    target("test")
        set_kind("shared")
        add_files("src/*.c")
        add_packages("libuv", "ffmpeg", "tbox", "zlib")

That's not how dependencies are discovered in cmake. Dependencies are added with calls to find_package, and if you have to include dependencies that don't install their cmake or even pkconfig module then you add your own Find<dependency>.cmake file to the project to search for it, set targets, and perform sanity checks.

* No standardization or opinionated design, so you can't share your work easily.

* No sane defaults, so your build system is always fragile, difficult to maintain, and done wrong.

* No best practices, so people keep making the same mistakes over and over.

* Misguided attempt to remain compatible with the steaming pile of legacy they've accumulated over the years.

* Bad documentation, so there's no way to learn how to do things better.

* Steep learning curve with limited payoff, so most people don't bother.

Meson does some of these things better. It's still not pretty, but it's nicer to use than CMake.

The answer is that CMake is mad and full of gotchas. Think of it like the PHP of build systems. Here is a classic example:

https://cmake.org/cmake/help/latest/command/if.html#variable...

You are very fortunate if you import libraries that just work. This is also true for "modern" CMake.

I.e. you just have to put all the source files from which you generate object files that will go in the same libray in a set of directories which does not contain files that will not go there.

Similarly, all the source files for the object files required for an executable, except those that are in libraries, should be in a set of directories.

The sets of directories need not be disjoint, just a given set must not contain files that must be excluded for linking a certain target, as that will make the building process more complex.

Given this constraints, it is possible to write a universal GNU makefile usable for any project, which will generate automatically all dependencies.

For any executable or library you want to build, it is enough to write an extremely small makefile, containing 4 lists (of defined symbols, of source files, of directories with header files and of libraries) and the name of the generated file and its type (excutable, shared library, static library).

At the end you need to include a makefile that is good for any project targetting a certain CPU + operating system combination.

The makefiles per CPU/OS must define a few things, e.g. the compiler used and other utilities, option flags for all, locations of the tools and so on, then you include a unique makefile for all architectures and operating systems.

I have started using this method more than twenty years ago and I have never ever needed to write manually any dependency information.

Whenever I see the huge and intricate and impossible to maintain makefiles that are too frequently encountered in many software projects, I wonder how one is willing to waste so much time with a non-essential part of the project.

From my point of view, building easily any large software project is a problem solved a long time ago by gcc & GNU make, but for reasons that I cannot understand most people choose to not do it in the right way.

Of course having to use in 2019 a programming language which does not implement modules by any better method than including header files is something even more difficult to understand, but I still must use C/C++ in my work, as there is no alternative for most embedded computers.

However, just because it is (like most build system questions) outside the scope of the standard does not mean that it isn’t possible to define some project-internal rules about what gets compiled and linked into what and that the build system cannot apply those rules to take work away from users.

The few external dependencies my project has are installed semiautomatically before any compilation starts.

As user, I find the experience with autotools to be much nicer as well. For whatever reason, the interface just seems more intuitive. I mean, ./configure --help will tell you basically all you need to know. An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want. I've run into more than one project that required a specific version of cmake, which as luck would have it, was not the version packaged with my distro. This leaves you either building another cmake first or finding a tool/library that isn't so persnickety.

Given the choice between trying a project that uses CMake or or autools, I'll choose the autotools based project every time.

"generate native makefiles" (I prefer Ninja myself) - this is what used to build software

Kind of like a container for building? I had to look it up myself.

That's the whole point of cmake. Instead of running autotool's ./configure (which in fact is a whole dance involving autoconf, autoreconf, automake, and whatnot) just run cmake . to get yourself a fancy makefile.

Most package manager use an offline signature mechanism done at build time (rpm, dpkg, nix) and do not rely on HTTPS security for anything else than eyes-dropping reasons.

Relying purely on HTTPS is insecure. Nothing guarantee you that your source / script / package did not get hacked / modified between the time you uploaded it and the time your user downloaded it.

This is not hypothetical scenario, it already happened in the past with sites like sourceforge.

Normally the packager and developer are different people so there is a second set of eyes to at least give a cursory glance to the changes. It takes more than a single compromised account to publish malicious changes. There are of course a million exceptions and caveats to this and it's not perfect, but it's better than allowing developers to push code directly.