boris

> Feature Detection Is Better than Version Detection

The problem with feature detection (normally referred to as configuration probing), at least the way it's done in ./configure and similar, is that it relies on compiling and potentially linking (and sometimes even running, which doesn't work when cross-compiling) of a test program and then assuming that if compilation/linking fails, then the feature is not available.

But the compilation/linking can fail for a myriad of other reasons: misconfigured toolchain, bug in test, etc. For example, there were a bunch of recent threads on this website where both GCC and Clang stopped accepting certain invalid C constructs which in turn broke a bunch of ./configure tests. And "broke" doesn't mean you get an error, it means your build now thinks the latest Fedora and Ubuntu all of a sudden don't have strlen().

Yes, pretty much. I think it would also be good (but admittedly risky) to accept third-party contributions (even new features) to the old version. In other words, instead of trying to force people to use a new license they could have tried to entice them.

I am not demanding anything, I am merely exploring if the "license rug pull" problem has a better solution. Redis paid dearly for it (justifiably or not) so if we can find a less costly option, wouldn't it be a good thing? I guess to put it another way, you are trying to change people's attitude towards open source while I am trying to see if there is a way around it.

They could still maintain it by, say, backporting bug fixes. And also accept contributions from people who prefer to stay on the old rug. It is extra effort for them and it is risky (everyone might end up staying on and contributing to the old rug turning it into the new new rug), but that's the price they would be paying for the goodwill.

I think you are missing my point: I am not saying there is no entitlement or that it's not bad (I've been on the receiving end to know it's true). I am merely wondering where it's coming from. Culturally, at least most of us, are conditioned to reciprocate.

Everyone agrees the unreasonable entitlement of many OSS users is bad but I don't see much analysis of where this entitlement comes from. Maybe it's the loss aversion: you first gift them the software but then by refusing to maintain it or add the feature that they need, you effectively take it away or, at least, suggest that they will have to pay for this gift after all (by implementing what they want themselves or paying someone to do it).

It could be the same dynamic with the "license rug pull", like in the Redis case discussed the other day. The new Redis license seems like it would be a non-issue for most users but because they had a more liberal license before and it was taken from them, they feel irrational sense of loss? (I realize there are also valid reasons why the BSD license was objectively better than the new custom license, like the ease of compliance.)

So maybe what Redis should have done is not to pull the existing rug, so to speak, but to leave it be and lay next to it a new, better rug and offer the users sitting on the old rug to move over, if they find the new features of the new rug outweigh the drawbacks of a new license.

> The only problem I've seen is that occasionally the server ssh process will get stuck, so you have to log in to the server and kill it.

You also need ClientAliveInterval on the server side (in addition to ServerAliveInterval on the client). In other words, both the client and the server need to be configured to monitor the connection. With this setup I had no issues with reconnections.

Based on my experience running open source projects for a couple of decades, not replying/engaging is the only way.

Don't reward incompetence with a response -- are they paying attention, have they done their homework? (paraphrasing Maria Popova)

The article lists some specific limitations of the meta build systems but doesn't really get to the underlying, fundamental issue with the approach. Which leaves the possibility of these specific limitations being addressed somehow and thus refuting the claim that meta build systems are fundamentally broken.

I think the fundamental issue boils down to aggregation. Normally, aggregation is a good thing, a variant of the divide and conquer technique which we were all taught in kindergarten you can never go wrong with. But in build systems aggregation leads to the loss of precision (rebuilding more than necessary) or accuracy (not rebuilding when necessary, rebuilding things in the wrong order), and usually both. This is the fundamental reason why "recursive make is considered harmful": we split one big graph that has the total, accurate view of all the dependencies into a number of aggregate sub-graphs. And the same happens with meta build systems where we do some part of the build (configuration, pre-build steps where we generate source code, etc) in the meta build system and the rest in the underlying build system, essentially splitting the graph into two.

P.S. And, yes, `build2` supports both dynamic prerequisites/dependencies[1] and dynamic targets[2].

[1] https://build2.org/release/0.15.0.xhtml#dyndep

[2] https://build2.org/release/0.16.0.xhtml#dyn-target

> Their pricing is either free or insane with little middle ground. I pleaded with a sales rep - I'm happy to stay on the free features but give you some money for "support" but they wouldn't take my money. Utter madness of a business model to turn down money.

It makes sense to turn down money if the administrative overhead of taking it will cost more. If I have to spend a couple of months negotiating a license/service agreement with your legal department and then chase your AP people for a couple months more to get my invoice paid, the the couple of $K you are willing to pay are not really worth it. And unfortunately that how things really work.

> Swift on Linux already and companies like Apple or Amazon are using it as well in production systems.

Hm, any citations on the latter? That is, companies like Apple and Amazon using Swift in production systems on Linux, especially for something similar to FDB? Thanks!

It may be improving but it's not there yet, let alone battle-tested with years of production use in serious applications on Linux. And we are talking about a distributed database here, where a bug can very well lead to it eating your data. Imagine PostgreSQL developers decided that, say, Zig will be their successor language. We would rightfully call them insane, no?

> Also, it might be niche on the backend, but it's definitely not niche overall.

I think it's safe to say it will always be a niche language on Linux, which is what matters here.

Here is recent report of trying Swift on a non-Mac OS platform, it's pretty damning:

https://flak.tedunangst.com/post/an-aborted-experiment-with-...

Strange... Presumably production deployments of FDB are on Linux. Last time I heard, Swift support on Linux is second-class. Is the plan to deploy on Mac OS instead of Linux? Or is Swift support on Linux sufficient for FDB needs?

I must say I am not a fan of this decision. FDB looked like a promising solution but not if it is tied to a niche language.

I am a C++ programmer and if you told me those things, I would just flip a bozo bit on you and carry on coding, no religious flame-war is warranted.

> I'll stand corrected on the technical details of the build2 implementation of modules.

Thank you.

> I still think the p1689 is a more robust implementation

I agree prescan has advantages, like being easier to integrate into existing build systems/analyzers/IDEs, but robustness is definitely not one of them. What can be more robust than the compiler asking the build system directly during compilation for the information it needs? Compared to the prescan, where the build system first scans the world with one set of command lines, digests the dependencies, and then starts invoking the compiler with another set of command lines.

Also, the mapper approach could be used to address other long-standing issues, like proper generated header support: https://wg21.link/P1842R0

> https://wg21.link/p1689

Ah, that. It's just a new -M output. It's still cannot handle header units though without a major extension to the preprocessor semantics, which so far only Clang managed to implement (for details, see https://developercommunity.visualstudio.com/t/scanDependenci... ; in particular notice how it was reported 1.5 years ago but is still unfixed).

> Does every analysis tool and IDE need to add support for that GCC specific API?

That besides the original point, which was that I claimed build2 supported this since 2021 to which you replied that it couldn't have.

build2 use the module mapper API which was available long before 2021: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Module-Mapper... You can try the examples here https://github.com/build2/cxx20-modules-examples/ with GCC 13 or 12 to confirm, if you wish.

> given communication APIs for GCC just landed in its main branch a month ago

Can you elaborate on what are these "communication APIs"?

> but not all library files are architecture-dependent.

While this is definitely true, the presence in /usr/share/ of many files from library packages on my system (Debian) still suggests that architecture-independent files should not go into /usr/lib/.

> See Python files at /usr/lib/python<version>

Aren't the compiled (.pyc) files in there architecture-dependent (or could be; genuine question, I have no idea)?

> /usr/include on the other hand only is used for C and C++ header files. Modules are not header files.

Yes, but it doesn't follow they cannot be installed there if that location is the most suitable from the distribution packaging point of view.

  └-- lib
          |-- cxx
          |   └-- foo.cppm     ---> this is a module interface (does `export module foo`)
          └-- libfoo.a

Hm, .../lib/ normally contains architecture-specific files so I wonder what was the rationale behind installing architecture-independent source code (foo.cppm is a source file) there instead of something architecture-independent like .../include/?

> So far, CMake 3.28 (still a Release Candidate at time of writing) is the only build system that implements dependency scanning and the ability to consume external libraries that provide modules, and the BMIs are built locally rather than distributed.

Hm, build2 was able to do this back in 2021: https://build2.org/blog/build2-cxx20-modules-gcc.xhtml And it was able to do it for both named modules and header units (the mentioned CMake release can only handle named modules).

The Makefile in the article is actually incorrect and only "works" by accident: main.o must have a dependency on mod1.pcm which is one of the outputs produced when compiling mod1.ccm and is needed whenever compiling any transaction unit that imports mod1.

> lack of flexibility compared to AMD's platform

You mean flexibility to claim ECC support but not doing any validation to make sure it actually works? Does any AMD motherboard manufacturer actualy states that "ECC is supported and has been validated"? I think the muddy waters that AMD has created would warrant such an explicit statement.

There are several plausible levels of "support" where ECC is concerned:

0. Not supported at all (i.e., if you plug ECC RAM, your system won't boot).

1. ECC RAM can be plugged but the ECC functionality is not used (i.e., there is no relevant traces/circuitry/etc).

2. ECC functionality is present (i.e., the circuitry is there) but it was not validated by the motherboard manufacturer to be functioning correctly (i.e., detecting/correcting errors).

3. ECC functionality is present and was validated by the motherboard manufacturer. This is the level one would expect from the server-grade boards from a reputable manufacturer like Supermicro.

In case of the AMD processors, when you see "ECC supported", it's anyone's guess which level it is. This is in contrast with Intel, where if it says CPU/chipset supports ECC, then you know it really does. I bet Intel won't allow a motherboards manufacturer to sell a board with chipset like W680 without validated ECC support.

As the name suggests, this wraps the whatever build system that the dependency is using rather than replacing it with Meson. Say if you depend on Boost and Qt, you will end up using both Boost Build and CMake in addition to Meson (most likely there will be a couple of more build systems if you are also building Boost's and Qt's own dependencies such as ICU). This has two major drawbacks:

1. The build in step-by-step rather than end-to-end. Meaning that you first build Boost completely, then Qt, and then your application. With an end-to-end build you would build everything with a single build system invocation with the build system "seeing" the entire build graph. In particular, this would allow you to build only what's necessary and faster.

2. If something goes wrong in one of these dependencies, you better be prepare to become an expert in whatever build system it uses.

If you want a true Cargo-like experience in C++, a better option would be build2, which replaces rather than wrapps the build system (and, yes, it has Boost and Qt packages): https://build2.org

For more details on what an end-to-end build can give you, see: https://build2.org/faq.xhtml#why-package-managers

> Unfortunately, it seems like this is a very specialized skill set that the vast majority of developers seem to find boring, uninteresting, and drudgerous, and finding someone qualified and interested has been exceedingly difficult.

The reason most find it boring, uninteresting, and drudgerous (I would also add "frustrating" to this list) is because one has to build on top of decades of bad decisions and quick hacks, over and over again. Which also suggests a way to make it interesting: make it about fixing the underlying problem (even if in a limited context) instead of just going along with whatever is available. For example, you can attempt to automate producing various packages from some "sane" common metadata.

You didn't provide much context on what exactly you are trying to package, but here is one example of what it might look like: https://build2.org/bpkg/doc/bpkg-pkg-bindist.xhtml

> I'd settle for people using stdout and stderr correctly.

I use this as a litmus test when looking at an unfamiliar codebase: if the author couldn't care less about writing diagnostics to stderr instead of stdout, there is little chance they cared to get more tricky stuff right.

Another test that goes hand in hand with this one is to check if error messages use a consistent style such as all start with a capital or small letter and all end or don't end with a period. Extra bonus points for using consistent quoting style.

The good guy who thought this would be the wrong decision all along but who got caught up in the middle of it has resigned. I bet people who thought (and perhaps still think) this was the right decision will not resign. Politics is a bitch.

Titanum.

One thing that seems to have helped (anecdote of 1) is getting a longer (quality) HDMI cable and making sure the end that connects to the MacBook goes in as straight as possible. As you may have noticed, there is quite a bit of play in that connector and I suspect having it at an angle degrades the connection.

> Qt should create a vanilla c++ package and tooling manager like Rusts cargo for dependencies and tools (and make semantic versioning mandatory). [...] Make the tool open source with vanilla c++ (aka non Qt projects), only so it can become the de facto standard.

Or just use one that is already working: https://build2.org (bonus point: also gets rid of CMake).

There are even "Qt classic" packages for both Qt5 and Qt6:

https://queue.stage.build2.org/?packages=Qt5

https://queue.stage.build2.org/?packages=Qt6