111–120 of 181 posts
Compared to Conan, what are the advantages?
Craft has project management and generates starter project structure. You can generate header and source files with boilerplate starter code. Craft manages the building of the project so you don’t need to write much CMake. You can also save project structures as templates and instantiate those templates in new projects ready to go.
As long as it's for C/C++ and not C or C++, I'm skeptical.
Why do you say this? I respect it, I'm just curious.
It signals that the speaker doesn't understand that the two are different languages with very different communities.
I don't really think that C users are entirely immune to dependency hell, if that's what OP meant, though. It is orthogonal.
As a user, I do believe it sucks when you depend on something that is not included by default on all target platforms(and you fail to include it and maintain it within your source tree*).
Earlier quoted context omitted.
Why do you say this? I respect it, I'm just curious.
C/C++ is HR-newspeak out of the 1990s(at the time it was not clear that anyone would still want to use C and MSVC did move their compiler to C++). It signals that the speaker doesn't understand that the two are different languages with very different communities. I don't really think that C users are entirely immune to dependency hell, if that's what OP meant, though. It is orthogonal. As a user, I do believe it suck…
Earlier quoted context omitted.
What?! seriously?! I’ve never heard of anyone doing that. If you use a cloud provider and use a remote development environment (VSCode remote/Jetbrains Gateway) then you’re wrong: cloud providers swap out the CPUs without telling you and can sell newer CPUs at older prices if theres less demand for the newer CPUs; you can’t rely on that. To take an old naming convention, even an E3-Xeon CPU is not equivalent to an E5…
… not everyone uses the cloud? Some people, gasp , run physical hardware, that they bought.
If you're deploying the binary to more than one machine, you quickly run into issues where the CPUs are different and you would need to rebuild for each of them. This is feasible if you have a couple of machines that you generally upgrade together, but quickly falls apart at just slightly more than 2 machines.
Earlier quoted context omitted.
What assumptions would that be? Shipping anything built with -march=native is a horrible idea. Even on homogeneous targets like one of the clouds, you never know if they'll e.g. switch CPU vendors. The correct thing to do is use microarch levels (e.g. x86-64-v2) or build fully generic if the target architecture doesn't have MA levels.
I build on the exact hardware I intend to deploy my software to and ship it to another machine with the same specs as the one it was built on. I am willing to hear arguments for other approaches.
And then, the binary that the end user receives will actually have been built on one of the CI systems. I bet they don't all have quite the same spec. And the above argument applies anyway.
Uses CMAKE, Sorry not for me. Call me old but i prefere good old make or batch. Maybe it's because i can understand those tools. Debugging CMAKE build problems made me hate it. Also i code for embedded CPU and most of the time CMAKE is just overkill and does not play well the compiler/binutils provided. The Platform independency is just not happening in those environments.
For simple projects. Make is easier for simple things I will grant. However when your projects gets complex at all make becomes a real pain and cmake becomes much easier. Cmake has a lot of warts, but they have also put a lot of effort into finding and fixing all those weird special cases. If your project uses CMake odds are high it will build anywhere.
Fighting the standard often creates it's own set of problems and nightmares that just aren't worth it. Especially true in C++ where yhou often have to integrate with other projects and their build systems. Way easier if you just use cmake like everyone else.
Even the old hold outs, boost and google open source, now use cmake for their open source stuff.
Earlier quoted context omitted.
C/C++ is HR-newspeak out of the 1990s(at the time it was not clear that anyone would still want to use C and MSVC did move their compiler to C++). It signals that the speaker doesn't understand that the two are different languages with very different communities. I don't really think that C users are entirely immune to dependency hell, if that's what OP meant, though. It is orthogonal. As a user, I do believe it suck…
What part of the build process is different for C?
It is probably true that more average C programs can be built with plain Makefiles or even without a Makefile than C++, though.
You can of course add dependencies on configure scripts, m4, cmake, go, python or rust when building a plain self-contained C program and indeed many do.
Earlier quoted context omitted.
Gentoo..... distributes binaries ?
Yes https://wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart
The distirbuted binaries use two standard instruction sets for x86-64 and one for arm like “march=x86-64-v3”
https://wiki.gentoo.org/wiki/Gentoo_binhost/Available_packag...