Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

xmake.io

Post reply on HN
Print view View original

41–50 of 57 posts

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

#41

Post by ensiferum »

jcelerier wrote: post #37
ensiferum wrote: post #30

Earlier quoted context omitted.

No, ofc nobody wants to do that and that's not really what I'm saying. I'm saying that all current build tools suck and can only ever decrease your software's value and decrease productivity. Let me illustrate. Your software is a product X. It has some value V (as by some measure of value, perhaps $ earned). The product X is the ultimate output of some build tool T. Now image you had this incredible build tool that p…

> 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 hav…

Right like I said some build tool can improve your productivity wrt to some other build tool. But did it create any absolute value in the end product?

Let's say you first build your product with autotools and you sell it for X$ per unit. If you later port your application to CMake. What value does CMake create in the end product? Can you sell it for more than X$ on the basis of having been built with Cmake? Usually no. The build system created 0 absolute value gain. You can claim that oh.. CMake is simpler than autotools and will save some time in the future thus creating a gain relative to autotools. Yet it's not capable of generating absolute value added. In absolute terms every build tool can only retract effort away from the activities that produce the value, i.e.software features.

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

#42

Post by Crinus »

waruqi wrote: post #35
Crinus wrote: post #34

I'm not sure how it differs from all the existing tools really, it looks like it does more or less the same stuff, just slightly differently. Also it does look like it requires that xmake is itself installed on the target system. Personally i'd like something similar to autotools, only much saner, in that you write some sort of script (or definition file or whatever) that describes your project and its requirements a…

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 ...

This still requires xmake to be installed. CMake does that too, as does Premake and a bunch of other tools, but they all need to be installed - except Autotools.

What i'm talking about is generating a script for something that is part of the OS itself (like shell script, which is what Autotools does) that itself generates the Makefile which uses a widely available standard tool (Make). So a user (i include library users - as opposed to library developers - as "users" here) wont need to install xmake/cmake/whatever just to build the program/library, they only need to have shell and make which are available everywhere. On Unix at least, on Windows it'd need to generate a batch file for MSVC (this is where Autotools fall short since they're made for unix only).

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

#43

Post by new_realist »

jandrewrogers wrote: post #24
troysand wrote: post #14

Earlier quoted context omitted.

You should definitely take a look at bazel. This is not say bazel is better than the one you wrote but cleary bazel is becoming a industry standard making other build tools obsolete.

The de facto industry standard is cmake, I have never even seen bazel in the wild and I work across many companies on big C++ code bases. I primarily use meson, and have even seen some cmake projects moved to meson, but I am under no illusions about it replacing cmake.

cmake is mediocre. Bazel is the future.

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

#44

Post by jstimpfle »

pjmlp wrote: post #38
kstenerud wrote: post #27

I so badly want to get off the C/C++ build system roller coaster. I've gone from make to autoconf to various IDEs to CMake to Meson, and have looked at a bunch of others but never made the jump. Eventually fatigue sets in, you pick a tech, and stick with it even as the tech fades into obscurity and nobody can figure out how to build your project anymore, let alone integrate it :/

I have it easy, MSBuild, and when not on Windows, CMake. Then again, I just need it to the extend of Java/.NET mixed builds with C++.

> MSBuild

OMG don't say the name, it causes me physical pain. That XML crap which can't decide whether to be a shitty static GUI-editable build format or a proper description language that you can actually use. It ended up being neither (to be fair the first can't really be achieved for non-trivial projects). It's one of the worst designs I've had to deal with.

(I'm still in the process of cleaning up hundreds of .vcxproj files, each of with has multiple 1000s of lines of auto-generated boilerplate in it, using the crutch that is .props files).

> and when not on Windows, CMake.

Even better, let's add another abomination, in the form of CMake, on top of MSBuild. And give up the last bit of control over your build that you could hope to have.

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

#45

Post by jcelerier »

ensiferum wrote: post #41
jcelerier wrote: post #37

Earlier quoted context omitted.

> 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 hav…

Right like I said some build tool can improve your productivity wrt to some other build tool. But did it create any absolute value in the end product? Let's say you first build your product with autotools and you sell it for X$ per unit. If you later port your application to CMake. What value does CMake create in the end product? Can you sell it for more than X$ on the basis of having been built with Cmake? Usually n…

> What value does CMake create in the end product? Can you sell it for more than X$ on the basis of having been built with Cmake? Usually no.

That is true for every technological choice.

> In absolute terms every build tool can only retract effort away from the activities that produce the value, i.e.software features.

Again you seem to think that build systems don't contain software features. I don't think that this is true. My build system helps me to refactor things that I would have to do by hand otherwise, and which are pretty project-specific. For instance scanning subprojects for their license information and generating a .cpp with that info, looking for all uses of a particular token and listing the files using that token for them to be included somewhere, etc etc.

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

#46

Post by jstimpfle »

jstimpfle wrote: post #44
pjmlp wrote: post #38

Earlier quoted context omitted.

I have it easy, MSBuild, and when not on Windows, CMake. Then again, I just need it to the extend of Java/.NET mixed builds with C++.

> MSBuild OMG don't say the name, it causes me physical pain. That XML crap which can't decide whether to be a shitty static GUI-editable build format or a proper description language that you can actually use. It ended up being neither (to be fair the first can't really be achieved for non-trivial projects). It's one of the worst designs I've had to deal with. (I'm still in the process of cleaning up hundreds of .vc…

But, let's not forget to mention, MSBuild the "execution engine" is absolutely fantastic... Working in Visual Studio, it reliably detects the minimal amount of things to rebuild.

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

#47

Post by alexeiz »

waruqi wrote: post #2

Xmake has its own package management repository. https://github.com/xmake-io/xmake-repo And it also supports self-built distributed repositories and third-party repositories (e.g. vcpkg, conan, clib, homebrew). 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",…

Using third party package repositories is a really, really smart move. This way you can expand the universe of available C++ packages by combining different package management systems. In my experience, Conan is already pretty solid. But if a package is not available in Conan, chances are it's available in Vcpkg.

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

#48

Post by bsder »

EliRivers wrote: post #20
bsder wrote: post #8

Earlier quoted context omitted.

Scons is effectively dead, and I wish people would start removing it from the Python build systems web pages. Meson is written in Python and isn't dead. However, Meson requires a partner to actually build things--something like cmake or ninja. However, I think the original poster meant "Why Lua instead of Python?" And the only real answer is "Because that's what the author wanted to use."

I only ever used SCons once, but it's had a handful of releases this year (containing what looks like some quite significant updates and improvements), the last being in August. In what way is it effectively dead?

It doesn't have any marquee products using it since, Blender, IIRC, dumped it.

For auxiliary things that you don't become expert in like source control, build systems, etc., it's vitally important to have a vibrant community around it so you can simply look up the answer and get back to your job. Or, you can have an emergent AI robot like Randal Schwartz, Wietse Venema, or Armin Rigo handle that support (seriously, do those guys ever sleep?). But you need to have one or the other, and Scons never seemed to.

I really don't understand why Scons never took off. I think it was simply that it was too early. Nobody actually cared about cross-platform in the sense of Windows/OS X/ Linux. Of course, Blender did care about that, and still dumped it. So, YMMV.

I think people only started to genuinely care about "cross platform" when developing both cloud code and client code simultaneously became a thing. And then that accelerated with the polyglot of languages layered on top of Javascript.

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

#49

Post by lightgreen »

pnako wrote: post #23
troysand wrote: post #14

Earlier quoted context omitted.

You should definitely take a look at bazel. This is not say bazel is better than the one you wrote but cleary bazel is becoming a industry standard making other build tools obsolete.

Bazel is an obscure tool mostly used by Google. The industry standard is CMake.

CMake today is autotools yesterday: too buggy, too unreliable, fragile, slow. Bazel is properly made build system.

Basically, CM does not guarantee correct incremental builds, Bazel does (I had to kill CM cache thousands of times to make sure everything is rebuilt correctly after changes in CMake definitions). CMake is incompatible with effective distributed building (you have to use cpp and distcc), Bazel is designed with distributed in mind. CMake is incompatible with effective caching (you have to use suboptimal ccache), Bazel has proper caching based on input checksums. CMake macros are pain, Bazel macros and custom rules are nice. And so on.

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

#50

Post by lightgreen »

reubenmorais wrote: post #25
flohofwoe wrote: post #22

Earlier quoted context omitted.

I'm sure once it works, bazel is great and all, but Windows seems to have been an afterthought (which makes that whole "industry standard" thing a bit "complicated"). The hoops one has to jump through to get it running on Windows are a joke (TBH, the list of prerequisites and potential issues looks like a UNIX programmer was confronted for the first time with Windows): https://docs.bazel.build/versions/1.1.0/install-…

Bazel, like most Google open source projects, has a strong focus on Google's internal needs. Another similar Bazel surprise is how many hoops you have to jump through for the rare task of... debugging a cc_binary on macOS: https://github.com/bazelbuild/bazel/issues/2537

I’d say it is Apple’s fault, not Google’s: Bazel correctly does not include absolute paths into binaries (Bazel focuses on build reproducibility which is very good for caching and debugging of builds), and Apple toolchain does not provide convenient way to work with such binaries.
Post reply on HN