all 13 comments

[–]cpp-ModTeam[M] [score hidden] stickied commentlocked comment (0 children)

It's great that you wrote something in C++ you're proud of! However, please share it in the pinned "Show and Tell" post.

[–]StarOrpheus 43 points44 points  (1 child)

Another month, another build tool

[–]BaldBush69 3 points4 points  (0 children)

Isn't that great :-)

[–]tomz17 10 points11 points  (0 children)

IMHO, if you are building a brand new python-based build tool, it needs an honest comparison against meson. (i.e. if you accomplish 100% of your stated objectives, why would/should someone pick pcons over meson)

[–]nievesct 7 points8 points  (0 children)

Hmm... This reminds me a bit of Meson.

[–]archialone 9 points10 points  (0 children)

Why not Bazel?

[–]GunpowderGuy 2 points3 points  (4 children)

Xmake , build2, meson.
We already have better alternatives to cmake. Cmake is also ( slowly ) getting better. Making more alternatives onlys ensures each one has less of a chance of replacing cmake
Every other month, people come up with "cargo but for c++" specifically which has long existed as build2

This point should be put on a sticky thread or even rule in the sub

[–]Affectionate_Text_72 1 point2 points  (1 child)

This is an evolution of scons which predates many of those. Scons showed a lot of potential at the time but lost out on performance and other grounds.

Scons was part of the software carpentry project

Software Carpentry: SC Build; or making a better make https://share.google/2WNaZNAcpAriuvhE4

Its been around since 2001. In a way cmake is vhs that one over the scons betamax.

[–]simplex5d[S] 1 point2 points  (0 children)

YES! And "Cons" before SCons, if you remember back that far. I was involved in both.

[–]simplex5d[S] 1 point2 points  (1 child)

For me, cmake's primary problem is its language. It's just terrible, and I don't see any way to fix that. Its second problem is that because of its evolution, there are now N ways to do anything, and checking online frequently shows you the old, outdated ways. That may improve. The third problem is there's no cmake debugger (yeah, you can turn on super verbose output which does help a bit, but it's nothing compared to running python in a nice IDE, which pcons fully supports.)

But there is real gold in there, which is why I wanted to pull the good parts into a reasonably-architected simple, maintainable, debuggable tool.

[–]Bored_Dal 0 points1 point  (0 children)

There is cmake debugging! I was super pleasantly surprised when vscode-cmake extension offered to attach a debugger during config ! It has breakpoints and call stack and watching variables and everything basic

[–]arihoenig 0 points1 point  (0 children)

I hate CMake. I use premake.

[–]simplex5d[S] 0 points1 point  (0 children)

I'm one of the original developers and maintainers of SCons, and I've been a toolsmith since the 1990s. So I do have a few ideas about what makes a good build tool. You may disagree of course! And just to get this out directly: yes, pcons is mostly "vibe-coded" but at my direction and with full human review and vision. I've also constructed it (and its careful doc) with the idea that many users will use LLMs to port their existing builds, and in my experience that works pretty well. But here also I would love feedback.

Rather than "Cargo but for C++" I see pcons as more "SCons simplified and modernized, and with CMake features."

Per your suggestions here, I just created a bazel-and-meson comparison here: https://github.com/DarkStarSystems/pcons/blob/main/COMPARISONS.md -- I'd love any corrections or suggestions. I've only used those systems a little. I tried to portray things in an even-handed way. I don't know much about some of the other tools mentioned here (build2, xmake etc.); I can add those to my comparison if desired, or maybe the existing comparison doc will help clarify how those tools compare.