Live data from Hacker News

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

github.com

121–130 of 190 posts

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

#121
post #14

Meson[0] has been gaining in popularity and has migration tools for cmake projects. Large projects such as systemd and gnome[1] have migrated or have been migrating for years [0] https://mesonbuild.com/ [1] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

AFAIK Meson requires a python installation, which is a non-trivial dependency and on some platforms requires additional manual setup steps. Having everything in a single standalone executable is vastly preferable IMHO.

It's pretty easy to install Python on Mac (use Brew) or Windows (use WinPython), and most Linux distros include it by default... running an installer is hardly an onerous task.

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

#122
post #107

Earlier quoted context omitted.

Actually it is, but nevertheless that's only required by those who for some reason still believe today that python2 vs python3 is an issue.

I have python 2 vs 3 issues if not every day, then at least 3 times a week, because of being stuck with a version of third party software that uses Python 2 (ArcGIS 10 series) for part of my code base. Of course Python apologists are now going to say 'oh you're just one guy in a niche situation', and 'yeah that's what you get for not upgrading to the latest version of all software', or any of the dozens of other excu…

In fairness to the python community by-and-large, they are very supportive of legacy users and niche configurations. Python 2.x seems like something like 15 years now past its sell by date and is still actively supported. There's a lot of patience there ... people will make the leap when they're ready.

I think the pressure to always be on the latest and greatest is what did for the ruby and perl communities, and this is why python, and to a certain extent javascript are still going strong!

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

#123

What I miss about these tools is some "relatively" straightforward dependency detection and generation. That is, I have a bunch of .cpp files which need to be compiled into individual executables in a folder bin/. I also have a folder inc/ which contains some headers (.h) and those headers possibly also have some associated TU (.cpp). Now g++ can already generate a dependency graph of headers for an executable. It is…

> Now g++ can already generate a dependency graph of headers for an executable.

Actually, it cannot; and this should be well known. It emits in practice less than half of the information that it knows from path lookup, that a build system really needs to know.

* https://news.ycombinator.com/item?id=15060146

* https://news.ycombinator.com/item?id=15044438

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

#124

Earlier quoted context omitted.

> if they'd just add a makefile (and maybe ./configure) 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.

if cmake was any good, the makefiles it produces would be portable, and distributing the cmake program itself would be unnecessary

CMake is doing more than generating a build file, it's also a configuration tool (detecting compiler, finding dependencies, etc).

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

#125

Earlier quoted context omitted.

Personally, I vastly prefer autotools, both as a user and developer. When I got to the point I needed some kind of build system, I found autotools much easier to learn than cmake. 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…

> An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want. sorry what ? I remember hours in my younger years searching which Debian package provided autowhateverflavoroftheday.sh so that I could build $random internet project

> > An underappreciated bonus is that you don't have to install more stuff just to __build__ some program you might not even want.

> sorry what ? I remember hours in my younger years searching which Debian package provided autowhateverflavoroftheday.sh so that I could build $random internet project

The whole point of Autotools is that distributed source packages can be built by themselves, without requiring any part of Autotools to be installed. They build even on obscure systems that don't have any working version of Autotools.

If you have to install autoanything to build a random project that uses Autotools, either you are doing something wrong, or the project is using Autotools wrong, or maybe the Debian package is using Autotools wrong.

That said, I know what you mean. I've had to seek out a number of different versions of Autotools just to get some things to build. But that is because a lot of projects and/or distro packaging blatantly uses Autotools differently than it's was designed to be used. I don't think Autotools should be blamed for this.

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

#127

Earlier quoted context omitted.

Unless you read and thoroughly understand the script first.

Not even then. The Server can detect if you pipe to a shell or just download the script: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Thanks for that. (Now I hate bash slightly more than I hated it already.)

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

#128
post #126

Im not a fan of LUA. The syntax of XMake.lua reads somewhat like CMake but easier to understand. What I'd really like to see is a build system in Python (3!) utilizing objects and dictionaries for tasks like this should be a breeze.

Just out of curiosity, what parts of lua do you not care for?

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

#129
post #126

Im not a fan of LUA. The syntax of XMake.lua reads somewhat like CMake but easier to understand. What I'd really like to see is a build system in Python (3!) utilizing objects and dictionaries for tasks like this should be a breeze.

Do you consider waf to meet that criteria? https://gitlab.com/ita1024/waf https://waf.io

Or scons? https://scons.org

Post reply on HN