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

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

github.com

Post reply on HN
Print view View original

171–180 of 190 posts

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

#171

Post by alexeiz »

flohofwoe wrote: post #98
2bluesc wrote: 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.

Depending on Python is actually much better than dependencies on other runtimes, just as Java. Firstly, Python is everywhere now. And secondly, you can just 'pip install --user' and use it even without root privileges (which is a great thing if you're in a restricted corporate environment).

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

#172

Post by shstalwart »

jcelerier wrote: post #139
jlokier wrote: post #125

Earlier quoted context omitted.

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

> 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. yes, it absolutely should be. If a tool is misused, it's generally because it's hard to use correctly…

> If a tool is misused, it's generally because it's hard to use correctly.

Citation needed.

Tools get misused all the time. If I use a flat bladed screw driver as a pry bar/chisel/whatever, that doesn't mean the flat bladed screw driver is hard to use.

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

#173

Post by Iwan-Zotow »

joshuamorton wrote: post #160
Iwan-Zotow wrote: post #155

Earlier quoted context omitted.

> I use cmake (well I don't often, but when I do) to build my projects. no, you don't remove from your system make (ninja, msbuild, ...) and see how cmake builds your project

>see how cmake builds your project Yes exactly when you remove a piece of the build system the build system stops working. When I use bazel I need python installed or it doesn't work. That doesn't mean my build system is python. It means my build system takes advantage of python. Same for cmake and make.

I'm sorry but make is not part of cmake build system. It predates cmake by decades. It is true build system used in by itself

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

#174

Post by Pete_D »

jlokier wrote: post #125
jcelerier wrote: post #99

Earlier quoted context omitted.

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

The portability is a very nice feature of autotools, but that distinction between developer sources and distributed sources it was designed around isn't as clear cut or widespread as it used to be. If I start a new C/C++ project today, chances are I expect users to be building from the git repo or a snapshot of it, rather than a semi-cooked tarball.

(I don't know what build system I'd pick these days - probably just write the Makefiles by hand.)

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

#175

Post by joshuamorton »

Iwan-Zotow wrote: post #173
joshuamorton wrote: post #160

Earlier quoted context omitted.

>see how cmake builds your project Yes exactly when you remove a piece of the build system the build system stops working. When I use bazel I need python installed or it doesn't work. That doesn't mean my build system is python. It means my build system takes advantage of python. Same for cmake and make.

I'm sorry but make is not part of cmake build system. It predates cmake by decades. It is true build system used in by itself

Yes. Make is a build system. Cmake is also a build system that leverages make. This means that from the perspective of a user of cmake, make is a component/dependency/part of cmake. make can be used independently, and is absolutely developed independently, of cmake.

But when you remove a dependency of a tool you can expect the tool to stop working. That doesn't mean that the tool doesn't do what it says it does.

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

#176

Post by pfranz »

lasagnaphil wrote: post #150
pfranz wrote: post #37

Earlier quoted context omitted.

Any new project will very, very likely be using Python3. It appears like that applies to meson. `python3` is the expected binary (`python` is still expected to point to Python 2 for the foreseeable future and `python2` being the explicit binary--some distros have jumped the gun on `python`). Similarly, they have completely different accompanies executables (pip3, wheel3, pydoc3) and completely separate library paths.…

On the contrary, Arch Linux has ‘python’ as Python 3 and ‘python2’ as Python 2. Although most of the Linux users are on Ubuntu, you can’t ignore those other distributions.

Arch was what I had in mind as an OS that jumped the gun against the advice of the Python devs (at least that's a simplified history). I thought there was another distro, but I wasn't sure if they had rolled that back.

To the point of the comment thread, that would only be an issue if you're maintaining a Python 2 codebase and using modern Arch. If you're creating a Python 3 codebase you're likely calling `python3` and even calling `python` isn't a problem for you.

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

#177

Post by pfranz »

NikkiA wrote: post #144
pfranz wrote: post #37

Earlier quoted context omitted.

Any new project will very, very likely be using Python3. It appears like that applies to meson. `python3` is the expected binary (`python` is still expected to point to Python 2 for the foreseeable future and `python2` being the explicit binary--some distros have jumped the gun on `python`). Similarly, they have completely different accompanies executables (pip3, wheel3, pydoc3) and completely separate library paths.…

The sooner debian kills the python = python2 association and python3 becomes the default provider of 'python' the better, I think I read that it's scheduled for this year finally.

I don't blame the OS guys. Python has been around for 30 years and many distros built a lot of their utilities around Python 2. Getting rid of Python 2 sounds like a Herculean effort that could only start after Python 3 settled down and required libraries were ported over (or replacement libraries written using more modern conventions).

I'm glad we seem to be past the big inflection point and hope to put Python 2 behind us. But I can see never changing `python` from Python 2 (just not have one when Python 2 isn't installed).

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

#178

Post by jcranberry »

robmccoll wrote: post #129
intea wrote: 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

Does waf still force you to be c++11/14?

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

#179

Post by pfranz »

rusk wrote: post #73
geezerjay wrote: post #45

Earlier quoted context omitted.

> Python also has version compatibility issues, such as: python2.x, 3.x. If that really bothers you then just create a virtual environment and locally deploy whatever version you want to run. That issue ceased to be a concern years ago.

> just create a virtual environment Yaw super lightweight ...

In other comments you talk about "lightweight" as cognitive load, I'm curious why Python is any different than other languages?

I haven't used virtualenv very much, but I've been doing similar things for longer than virtualenv has been around. You need a `python` binary on PATH and a PYTHONPATH pointing to where you want to get your libraries from. virtualenv packages this up into a directory in a more user friendly fashion.

Most docs I've seen on Python2/3 advise on choosing one or the other, ideally 3. Which implies mixing should either be done very carefully or with a plan to transition to 3.

I get that some accidents of history have caused headaches. The deep adoption by distros have caused problems when people just want to use Python/libs installed with the OS (as well as moving to Python 3), authoring packages hasn't been great historically, etc.

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

#180

Post by HelloNurse »

IshKebab wrote: post #132
ridiculous_fish wrote: post #30

Earlier quoted context omitted.

Why migrate from CMake to meson?

Nobody who has used CMake would ask that so I assume you haven't! 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...

This is a reasonable programming language design choice.

CMake actual gotchas I dislike enough to avoid it as much as possible include defaulting to cached information, even after I make changes, and preferring "smart", opaque and even hard to track down scripts to explicit user input. It seems optimized for cleverness and conciseness, at the expense of reliability and required user effort.

Post reply on HN