Hacker News Reader

Comment by jpc0 | Hacker News Reader

CMake, the defacto if not standard build system, when correctly setup, does all this for you.

Your argument is along the lines of "the maintainer of X rust package didn't setup cargo correctly and it's impossible to include in my project, rust is a horrible language". You can absolutely make an argument that the lack of a standard build system is a pain point, and well it's C++ you get to be a special snowflake and use a makefile instead of CMake but then the onus is on you to provide correct documentation.

View on HN

In the case of duckdb they provide proper packages for pip, cargo, npm, go get, and the only one that seems like a PITA to use is the C/C++ dependencies, even though the package is written is C++, so I think this tells something about C++ dependency management

Seeing as it's Christmas Eve and I has nothing better to do...

Duckdb own documentation says the C++ API is internal and you should use the C API[1]

The makefile also has a 'bundle-library' option which seems to be exactly what you were looking for, it generates a statically linked library which is what the Golang package is using, probably others too but that's the one I checked first.

This is purely a documentation problem, the build system does what is needed it seems. Create an issue, or better yet, add the necessary documentation...

1. https://duckdb.org/docs/api/cpp

I used the C api but I did miss the 'bundle-library' option, will look into that

I definitely don't blame you for missing it.

I found it by looking at the go package because they claimed they are statically linking there.

You seem to be agreeing with me then, weird take to do it while sounding like you disagree...

As I said, you can make the argument C++ build systems are no good. However the argument originally made is that C++ the language caused these issues when in reality the package maintainer hasn't put in the effort to properly document and fix known issues in their chosen build system for C++.

The fact that they in fact have built out proper packages for pip, cargo, npm and go tells me they have the necessary expertise on the team and made an active choice to not do the same for C++. Create an issue with the maintainer.

The argument originally made was "You can read front-to-cover books about every details of C++ semantics and it'll still be a PITA to work on real world projects"

Which is not disagreeing with you just because you are explaining/disputing the reason it was a PITA.

That statment was qualified by:

> While I'm far from a cmake/cpp expert, this is a non-issue with most modern languages: you just pip install, cargo add, npm install, go get etc.

Which I also find fundamentally wrong because most real world projects have a C/C++ dependency which needs to be built and is built from one of those languages build systems by calling into cmake / autotools + make.

Just because you called apt-get or any other way to pull dependencies doesn't remove the fact that they need to be built and likely involve a C compiler.

I have seen way more projects with very broken CMake integration than rust packages with broken cargo setup.

CMake is a pain.

> the maintainer of X rust package didn't setup cargo correctly and it's impossible to include in my project

That basically never happens, which is the point.

Reply on news.ycombinator.com