7 ms·

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

89 points by waruqi 7y ago

waruqi 7y ago
Xmake has its own package management repository.https://github.com/xmake-io/xmake-repo 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", "zlib")
- derin 7y ago
  Just as a heads up, you should probably remove the yaourt xmake section of the install section (the Arch Linux instructions). Yaourt is no longer actively maintained and poses security risks. Just linking to the AUR package is usually enough.
  - waruqi 7y ago
    Ok, I will look at it. Thanks!
- jchw 7y ago
  Interesting. Visually, it looks a lot like Meson's Mesonfile syntax, in some ways. Does the indentation have semantic meaning at all, or is it just to convey a hierarchy?
  - kitd 7y ago
    No, the indentation is for human readability only.
    - waruqi 7y ago
      Yes.
- alexeiz 7y ago
  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.
jauer 7y ago
Looks cool, but is there a tl;dr for why I’d use this instead of something like Bazel?
- kitd 7y ago
  I'm not related to xmake, but it seems a much simpler project than Bazel, which is much more opinionated and contains many more bells and whistles. Bazel may be suited for large, structured (read 'enterprise') code bases, but I can see as big a market for something like this as well.
- waruqi 7y ago
  I haven't compared it to bazel, but if you like the description style of xmake for the project or you like lua, you can try it.
  - troysand 7y ago
    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.
    - waruqi 7y ago
      Ok, I will look at it, as far as I know, cmake seems to be more popular than bazel. At least I rarely see projects that use bazel, although I don’t like the syntax of cmake very much.
      - Onanymous 7y ago
        yes, I guess comparing with the de-facto standard solution (cmake) would be more beneficial.
    - flohofwoe 7y ago
      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-windows.html https://docs.bazel.build/versions/1.1.0/install-windows.html
loose_pants 7y ago
Why not Python? Syntax is much cleaner and there’s nothing you can’t achieve. Even performance is on par.
- jacobush 7y ago
  Python as in Scons? Otherwise I don't understand your comment.
  - bsder 7y ago
    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."
    - EliRivers 7y ago
      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?
      - bsder 7y ago
        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.
tbfly 7y ago
Great tools, good job!
kstenerud 7y ago
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 :/
- pjmlp 7y ago
  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++.
  - jstimpfle 7y ago
    > 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.
    - jstimpfle 7y ago
      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.
      - lightgreen 7y ago
        > it reliably detects the minimal amount of things to rebuild So they managed to implement graph traversal which is a basic interview question everywhere? Every dummy build system do it, but for Microsoft that’s achievement!
ensiferum 7y ago
Unfortunately no build tool can ever really improve productivity in absolute terms. They can only ever "improve" relatively, i.e by sucking less and reducing productivity less than some other competing build tools. The time that is spent dicking around with these silly build systems/tools is always time that is wasted and sank into useless activities without any value added in the end product.
- imtringued 7y ago
  I completely disagree. Do you want to go back to typing g++ commands by hand for each source file? That's not a build tool and yet it is objectively worse than even a crappy build tool.
  - ensiferum 7y ago
    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 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! Now in reality you spend some amount of time writing build files, working with the build, fixing bugs in the build files, generally maintaining it. This is typically non zero effort and the cost grows above linearly wrt respect to build configurations/platforms supported etc. However the output of the build tool is still the same X and value is still V. So your build tool added 0 value! In fact any build tool can only ever decrease your product's value. Why? How? Because of the cost of messing with the build is non-zero and you spend time on it that could otherwise be spent working on actual things that produce more value (such as adding new features or fixing bugs or whatever). i.e. you can only put 100% - "build effort" amount of effort towards working on X and increasing V.
    - jcelerier 7y ago
ensiferum 7y ago
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.
- Crinus 7y ago
  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.
- jcelerier 7y ago
  > If there are any unresolvable ambiquieties then ask me. what if there is no ambiguity, only a single wrong answer, and now it "works" but you include the wrong thing ? > - 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? because adding -pthread and -lpthread have different semantics (-pthread defines _REENTRANT which may change things - grep your /usr/include for that ;p) and you may want one or the other regardless of whether you use std::thread. > - 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? which linker libs ? on my computer I must have 5 version of those right now, not counting UWP and various MinGW versions. Also sometimes I want the debug standard library and sometimes not. > - 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? determining if you are using C++14 features sounds like a corollary of the halting problem
Crinus 7y ago
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 and then the tool generates a configure shell script for unix and windows (i mean two configure scripts, one for unix and one for windows) that itself generates a makefile and/or project file. So, like autotools, the recipient of the code will not need to have your magic build tool installed, just the common tools available on their system (shell, make, cc for unix/mingw, visual studio or whatever on windows). This can be very useful especially for libraries (it is annoying when every library wants its own special snowflake build tool).
- waruqi 7y ago
  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 ...
  - Crinus 7y ago
    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).
pornel 7y ago
There are so many nice build tools for C, but unfortunately very few users will be happy to install and learn yet another tool. And no matter which build system you choose, you'll find users who think your choice is awful and you should have picked their one true build system.

89 points by waruqi 7y ago

Xmake has its own package management repository.https://github.com/xmake-io/xmake-repo 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", "zlib")

derin 7y ago
Just as a heads up, you should probably remove the yaourt xmake section of the install section (the Arch Linux instructions). Yaourt is no longer actively maintained and poses security risks. Just linking to the AUR package is usually enough.
- waruqi 7y ago
  Ok, I will look at it. Thanks!
jchw 7y ago
Interesting. Visually, it looks a lot like Meson's Mesonfile syntax, in some ways. Does the indentation have semantic meaning at all, or is it just to convey a hierarchy?
- kitd 7y ago
  No, the indentation is for human readability only.
  - waruqi 7y ago
    Yes.
alexeiz 7y ago
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.

jauer 7y ago

Looks cool, but is there a tl;dr for why I’d use this instead of something like Bazel?

kitd 7y ago
I'm not related to xmake, but it seems a much simpler project than Bazel, which is much more opinionated and contains many more bells and whistles. Bazel may be suited for large, structured (read 'enterprise') code bases, but I can see as big a market for something like this as well.
waruqi 7y ago
I haven't compared it to bazel, but if you like the description style of xmake for the project or you like lua, you can try it.
- troysand 7y ago
  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.
  - waruqi 7y ago
    Ok, I will look at it, as far as I know, cmake seems to be more popular than bazel. At least I rarely see projects that use bazel, although I don’t like the syntax of cmake very much.
    - Onanymous 7y ago
      yes, I guess comparing with the de-facto standard solution (cmake) would be more beneficial.
  - flohofwoe 7y ago
    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-windows.html https://docs.bazel.build/versions/1.1.0/install-windows.html

loose_pants 7y ago

Why not Python? Syntax is much cleaner and there’s nothing you can’t achieve. Even performance is on par.

jacobush 7y ago
Python as in Scons? Otherwise I don't understand your comment.
- bsder 7y ago
  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."
  - EliRivers 7y ago
    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?
    - bsder 7y ago
      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.

tbfly 7y ago

Great tools, good job!

kstenerud 7y ago

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 :/

pjmlp 7y ago
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++.
- jstimpfle 7y ago
  > 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.
  - jstimpfle 7y ago
    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.
    - lightgreen 7y ago
      > it reliably detects the minimal amount of things to rebuild So they managed to implement graph traversal which is a basic interview question everywhere? Every dummy build system do it, but for Microsoft that’s achievement!

ensiferum 7y ago

Unfortunately no build tool can ever really improve productivity in absolute terms. They can only ever "improve" relatively, i.e by sucking less and reducing productivity less than some other competing build tools. The time that is spent dicking around with these silly build systems/tools is always time that is wasted and sank into useless activities without any value added in the end product.

imtringued 7y ago
I completely disagree. Do you want to go back to typing g++ commands by hand for each source file? That's not a build tool and yet it is objectively worse than even a crappy build tool.
- ensiferum 7y ago
  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 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! Now in reality you spend some amount of time writing build files, working with the build, fixing bugs in the build files, generally maintaining it. This is typically non zero effort and the cost grows above linearly wrt respect to build configurations/platforms supported etc. However the output of the build tool is still the same X and value is still V. So your build tool added 0 value! In fact any build tool can only ever decrease your product's value. Why? How? Because of the cost of messing with the build is non-zero and you spend time on it that could otherwise be spent working on actual things that produce more value (such as adding new features or fixing bugs or whatever). i.e. you can only put 100% - "build effort" amount of effort towards working on X and increasing V.
  - jcelerier 7y ago

ensiferum 7y ago

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.

Crinus 7y ago
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.
jcelerier 7y ago
> If there are any unresolvable ambiquieties then ask me. what if there is no ambiguity, only a single wrong answer, and now it "works" but you include the wrong thing ? > - 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? because adding -pthread and -lpthread have different semantics (-pthread defines _REENTRANT which may change things - grep your /usr/include for that ;p) and you may want one or the other regardless of whether you use std::thread. > - 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? which linker libs ? on my computer I must have 5 version of those right now, not counting UWP and various MinGW versions. Also sometimes I want the debug standard library and sometimes not. > - 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? determining if you are using C++14 features sounds like a corollary of the halting problem

Crinus 7y ago

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 and then the tool generates a configure shell script for unix and windows (i mean two configure scripts, one for unix and one for windows) that itself generates a makefile and/or project file. So, like autotools, the recipient of the code will not need to have your magic build tool installed, just the common tools available on their system (shell, make, cc for unix/mingw, visual studio or whatever on windows). This can be very useful especially for libraries (it is annoying when every library wants its own special snowflake build tool).

waruqi 7y ago
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 ...
- Crinus 7y ago
  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).

pornel 7y ago

There are so many nice build tools for C, but unfortunately very few users will be happy to install and learn yet another tool. And no matter which build system you choose, you'll find users who think your choice is awful and you should have picked their one true build system.