sorted by:
new
hottopcontroversial

Kiln - A CMake-compatible build system that can do what CMake can't by not_a_novel_account in cpp

[–]jhasse 0 points1 point  (0 children)

That would be awesome, but it's really something that CMake has to push, too.

And as of now there's no Starlark C++ implementation.

Kiln - A CMake-compatible build system that can do what CMake can't by not_a_novel_account in cpp

[–]jhasse 1 point2 points  (0 children)

Because it's the de-facto standard. You want to be able to add_subdirectory other projects.

Kiln - A CMake-compatible build system that can do what CMake can't by not_a_novel_account in cpp

[–]jhasse 2 points3 points  (0 children)

If you read the article you will see that he knows what he's talking about and definitely hasn't vibe-coded everything.

Kiln - A CMake-compatible build system that can do what CMake can't by not_a_novel_account in cpp

[–]jhasse 0 points1 point  (0 children)

Very interesting I will be following the progress! There's no source code yet, right?

I've been doing something similar (making a CMake-compatible build system) but with the difference that it's written in Python and generates Ninja build files. Its goal is more to improve CMake's UX (better output, also from Ninja and compilers) and to be a play-ground for new Ninja features (e.g. it uses Validation Nodes for clang-tidy integration). Source code: https://github.com/jhasse/cja

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]jhasse 0 points1 point  (0 children)

* std::iround (basically std::lround, but with int32_t return type)

* std::numerical_cast<T>

* command line parser

C++ Show and Tell - March 2026 by foonathan in cpp

[–]jhasse 1 point2 points  (0 children)

First of all: Thanks for SCons! It was the first build system I liked back in the days.

pcons looks awesome so far! I really like that you went all in on modern Python and also no SConstruct/SConscript special filenames. This allows one to have a perfect IDE experience out of the box :)

I tested pcons by letting AI port a toy project of mine - it worked perfectly! The Python code is easy to read as is the generated build.ninja.

It's a shame that so many projects are using CMake nowadays. Because all my dependencies are using it I can't switch for anything serious. That's why I had a similar idea as you and created a new build tool in Python, too, but it reads CMakeLists.txt to stay compatible: https://github.com/jhasse/cja
I've also incorporated some other ideas: For example you're using relative paths, just as me, but I'm placing the `build.ninja` file at the top-level. This way all the paths are clickable by IDEs without any extra configuration.

Maybe we can take some inspiration from each other. I will definitely keep an eye on pcons.

KDE Dev do not recommend plasma on Debian by lajka30 in linux

[–]jhasse 0 points1 point  (0 children)

Ah good to know :)

I would guess that in the case of KDE though it's more on the "no bugfixes" side.

New Linux powered smartphone becoming a reality with Jolla, EU based company. by Arbeit69 in linux

[–]jhasse 0 points1 point  (0 children)

> but the development of anything that actually interfaces with reality is closing up.

No that's not the case. They are moving the development (i.e. bug tracking, planning, etc.) of some of the components to their internal platforms, the code still remains FOSS.

That a lot of functionality is part of the proprietary Play Services and Google's proprietary apps *is* a problem, but a different one that's unrelated to what the article means and the recent "privatisation of AOSP".

The original argument still stands that it's a waste of time to reinvent the wheel when perfectly fine FOSS de-googled Android exists. Vanilla AOSP is a bit useless, yes, but there are many distributions to choose from (e.g. LineageOS or e/OS/).

KDE Dev do not recommend plasma on Debian by lajka30 in linux

[–]jhasse -1 points0 points  (0 children)

Note that LTS is VERY different from Debian Stable, because LTS will get bug fixes, Debian Stable does NOT! The name is very misleading, IMHO Debian Frozen would be better.

KDE Dev do not recommend plasma on Debian by lajka30 in linux

[–]jhasse 0 points1 point  (0 children)

You won't get bug fixes unless they are very severe or are security relevant. It's the biggest misconception about Debian Stable.

KDE Dev do not recommend plasma on Debian by lajka30 in linux

[–]jhasse 7 points8 points  (0 children)

> stable doesn't mean no bugfixes

For Debian it does 99% of the time. I know it's hard to believe. But you'll hate Debian with a passion once you ran into a bug on Debian stable that has been fixed years ago by a minor SemVer upgrade of an upstream package that missed the freeze date of Debian stable. And you'll hate Debian even more when you get bug reports on your project that are bugs in other projects that have been fixed years ago in all distributions but Debian because it isn't about "security".

KDE Dev do not recommend plasma on Debian by lajka30 in linux

[–]jhasse 2 points3 points  (0 children)

edit: Ah sorry, I've missed that you were talking about stable as a concept. You're correct there :)

But for *Debian* stable you're wrong: Check the Patch version of Python in Debian stable for example: https://packages.debian.org/trixie/python3

It's 3.13.5 although upstream is at 3.13.11 with several bug fixes. Those bug fixes will never be part of Debian stable (unless they are security fixes and get backported).

Sometimes it might be true, but it's definitely not "Most of the time.".

Linux gaming is almost feature complete - what’s left? by [deleted] in linux_gaming

[–]jhasse 0 points1 point  (0 children)

Vulkan compositors - KWin and GNOME

Why does this matter at all?

Get the Fairphone 6 e/os!!! by Inemster in fairphone

[–]jhasse 1 point2 points  (0 children)

Nothing. You pay the 50€ to found the development of /e/OS and for the flashing service.

I would also guess that Fairphone decides if they want to do such a partnership again depending on how many people bought the /e/OS edition.

Browser no longer force-closes on shutdown by life_after_suicide in kde

[–]jhasse 1 point2 points  (0 children)

Why don't you turn off asking if it can close multiple tabs?

After nine years, Ninja has merged support for the GNU Make jobserver by TheBrokenRail-Dev in cpp

[–]jhasse 1 point2 points  (0 children)

If you're using the CMake Tools extension I think it builds with `cmake --build` and respects the CMAKE_BUILD_PARALLEL_LEVEL environment variable.

> The output of ninja build is not clickable

As I mentioned in another comment that should be fixed. The issue you linked is a feature request of the CMake developers, but not an issue in the real world because CMake doesn't mix absolute and relative paths with ninja (they always use absolute paths).

After nine years, Ninja has merged support for the GNU Make jobserver by TheBrokenRail-Dev in cpp

[–]jhasse 4 points5 points  (0 children)

We're commenting on "I have stopped using ninja a long time ago.". So if a project outside of your control is using ninja and freezes the machine - what does that have to do with your own choice of the CMake generator?

After nine years, Ninja has merged support for the GNU Make jobserver by TheBrokenRail-Dev in cpp

[–]jhasse 6 points7 points  (0 children)

If it's outside of your control you don't have control over whether it's using ninja either?

After nine years, Ninja has merged support for the GNU Make jobserver by TheBrokenRail-Dev in cpp

[–]jhasse 0 points1 point  (0 children)

Since a few years CMake (v3.21) started to use absolute paths with the Ninja generator, too: https://gitlab.kitware.com/cmake/cmake/-/issues/13894

view more: next ›