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.
Show HN: Xmake, a modern C/C++ build utility
121–130 of 190 posts
Re: Show HN: Xmake, a modern C/C++ build utility
#122Earlier 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…
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
#123What 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…
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.
Re: Show HN: Xmake, a modern C/C++ build utility
#124Earlier 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
Re: Show HN: Xmake, a modern C/C++ build utility
#125Earlier 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
> 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
#126Re: Show HN: Xmake, a modern C/C++ build utility
#127Earlier 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...
Re: Show HN: Xmake, a modern C/C++ build utility
#128Im 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.
Re: Show HN: Xmake, a modern C/C++ build utility
#129Im 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.
Or scons? https://scons.org