Earlier quoted context omitted.
What do embedded projects in US use instead?
Plain ol' makefiles?
Can you not use CMake to generate those makefiles?
CMake Part 1 – The Dark Arts
61–70 of 70 posts
Re: CMake Part 1 – The Dark Arts
#62Earlier quoted context omitted.
I did not know about rev, thanks. Though, since there is no way to specify a signature you are forced to use potentially outdated packages.
"cargo update" will update the packages along with Cargo.lock content. As for not updating them without a manual trigger, I consider it a feature, but I guess it's a matter of opinion.
> "cargo update" will update the packages along with Cargo.lock content
Disregarding the rev attribute?
Re: CMake Part 1 – The Dark Arts
#63Earlier quoted context omitted.
I'm not sure you understood what I've said at all. CMake eliminates boilerplate code and compiler checks. They do not exist, at all. With CMake you state that you have a C++11/14/17/20 project, it builds N static/shared libs and M executables, you set dependencies, and you're done. They do exist in Makefile projects because Makefiles only define the DAG for the build, and don't perform any sanity check at all. So if…
> Checking if the compiler you're using supports a specific version of C++ is not evil or superfluous. It is both evil and superfluous. It is evil because you should be writing portable code and do not depend on compiler specificities. It is superfluous because if you do not check, the compilation will still fail, which is precisely the expected behaviour. > How exactly do you think simple, portable code is done? By…
> It is both evil and superfluous. It is evil because you should be writing portable code and do not depend on compiler specificities. It is superfluous because if you do not check, the compilation will still fail, which is precisely the expected behaviour.
But now I get 2 dozen error reports because there is a lot of users who run builds because they're on Linux and that's what $BLOGPOST said to do to have the last version of some software, but have no clue about software development.
> No, of course. At first you will have a few linuxisms or macOS-isms, that you will gradually remove through a few rounds of multi-platform testing (which is free and easy to do nowadays).
So how do you handle that you need to link against Ws2_32 on windows or "-lwebsocket.js -s PROXY_POSIX_SOCKETS=1 -s USE_PTHREADS=1 -s PROXY_TO_PTHREAD=1" on emscripten if you want to use sockets ? Don't use sockets because they're not portable ?
Re: CMake Part 1 – The Dark Arts
#64Earlier quoted context omitted.
"cargo update" will update the packages along with Cargo.lock content. As for not updating them without a manual trigger, I consider it a feature, but I guess it's a matter of opinion.
> "cargo update" will update the packages along with Cargo.lock content Disregarding the rev attribute?
This is the entire point of this command. It will update the rev attribute. What else would it be for?
Re: CMake Part 1 – The Dark Arts
#65CMake is legitimately the worst software I've ever used. cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake
Crazy, I'd definitely use CMake above autotools (does not even work natively on windows LOL), handwritten makefiles (not supporting filenames with spaces in 2021 LOL), "the IDE" (do you even do cross-platform?). I'd use Bazel but afaik it mostly uses a rebuild-the-world approach.. I'm already getting flak from Linux distros maintainers because I use some vendored header-only libraries and not system ones so I don't s…
Bazel does the opposite of rebuild-the-world. That's more of a CMake thing (rm -rf build && mkdir build && cd build && cmake ..). Bazel won't even run tests if the code the tests depend on have not changed. A lot of thought went into Bazel. It caches everything it possibly can.
> I'm already getting flak from Linux distros maintainers because I use some vendored header-only libraries and not system ones so I don't see how that is even supposed to work.
That's where you use autotools. It has been around long enough that every package manager knows how to deal with it. For most C/C++ programs, autotools is all you need. You should learn it because it's not going away.
"the IDE" (like VS project files) is definitely not cross-platform (although it can be), but not everything needs to be cross platform. For game devs building on DirectX, for example, it's completely pointless to support other platforms when the runtime depends on a single platform.
Re: CMake Part 1 – The Dark Arts
#66Earlier quoted context omitted.
Maybe it wasn't your intention, but your comment is the most scathing critique I've ever read of cmake. Boilerplate code and "compiler checks" are strongly negative anti-patterns. Maybe the worst in programming. That cmake makes it easy to do these awful things just shows how evil it is! People: write simple, portable code!
> People: write simple, portable code! that does not work as soon as your users are on both windows and a unix-like platform and you are making a non-trivial app (for instance, an app with networking, audio, and video support). A simple example: how do you share a GPU texture handle across multiple processes portably with a single code that works across windows / mac / linux's graphics APIs ?
Trying to do that is a massive waste of time. It's legitimately easier to maintain separate codebases for each of the different platforms. The code that doesn't need to change can be a library. Or you use some super high level abstraction like Unity, Qt, JVM, Electron, React Native. Portability != cross-platform.
Re: CMake Part 1 – The Dark Arts
#67Earlier quoted context omitted.
Crazy, I'd definitely use CMake above autotools (does not even work natively on windows LOL), handwritten makefiles (not supporting filenames with spaces in 2021 LOL), "the IDE" (do you even do cross-platform?). I'd use Bazel but afaik it mostly uses a rebuild-the-world approach.. I'm already getting flak from Linux distros maintainers because I use some vendored header-only libraries and not system ones so I don't s…
Bazel does the opposite of rebuild-the-world. That's more of a CMake thing (rm -rf build && mkdir build && cd build && cmake ..). Bazel won't even run tests if the code the tests depend on have not changed. A lot of thought went into Bazel. It caches everything it possibly can. > I'm already getting flak from Linux distros maintainers because I use some vendored header-only libraries and not system ones so I don't se…
> Bazel does the opposite of rebuild-the-world.
by "rebuild the world" I don't mean "do a clean rebuild" (which frankly isn't a problem in 2021 with CMake + Ninja, the last time I had to rebuild is when the compiler changed from clang-11 to clang-12) but "to build a bazel-based software, all its dependencies must be built with bazel too", e.g. it's harder if you want to link against system-provided Qt, ffmpeg, ...
> That's where you use autotools. It has been around long enough that every package manager knows how to deal with it.
and yet it still sucks on windows if you want to use cl.exe (or if you want Xcode / VS solutions, which is regularly my case).
Re: CMake Part 1 – The Dark Arts
#68Earlier quoted context omitted.
You missed the point. "__CLASSIC_C__" is not a thing (why they don't use __STDC__? I don't know, they don't seem to know either) and the syntax that they use inside that ifdef is.. not what people mean by classic C. It has been there for years and multiple people have pointed it out but they do not seem to care. The funny thing is that they do know how to use the pre-standard C argument syntax (as in https://gitlab.k…
> You missed the point. "__CLASSIC_C__" is not a thing (why they don't use __STDC__? I dont know, I'm not going to defend it. Imnot going to do a line by line review of the file you picked, as I said I'm sure I can find awful code in bazel, meson, etc. > Also, I have been told that cmake-generated Makefiles invoke cmake itself, so you can't really generate portable Makefiles with it. Cmake generates a target for make…
> as I said I'm sure I can find awful code in bazel, meson, etc.
Oh, you have proof that person X murdered someone? I am sure I can find awful stuff that person Y and Z did!
[back in 2014] OpenSSL has heartbleed? Well, I am sure that I can find issues in libsodium if I looked.
> Do you compile your own make regularly?
No, my users however might need to once they have to deal with a cmake project.
> but it's definitely doable (maybe 5 or so minutes?)
I was told that it takes hours, though I might be misremembering.
> so I can focus on my library or application code.
This kind of thing does not really distract you from anything. Adding something like that takes as long as it does to add a cmake check. Then the person who is compiling has to do -DENABLE_FEATURE=1.
Re: CMake Part 1 – The Dark Arts
#69Earlier quoted context omitted.
> You missed the point. "__CLASSIC_C__" is not a thing (why they don't use __STDC__? I dont know, I'm not going to defend it. Imnot going to do a line by line review of the file you picked, as I said I'm sure I can find awful code in bazel, meson, etc. > Also, I have been told that cmake-generated Makefiles invoke cmake itself, so you can't really generate portable Makefiles with it. Cmake generates a target for make…
> as I said I'm sure I can find awful code in bazel, meson, etc. Oh, you have proof that person X murdered someone? I am sure I can find awful stuff that person Y and Z did! [back in 2014] OpenSSL has heartbleed? Well, I am sure that I can find issues in libsodium if I looked. > Do you compile your own make regularly? No, my users however might need to once they have to deal with a cmake project. > but it's definitel…
> Oh, you have proof that person X murdered someone? I am sure I can find awful stuff that person Y and Z did!
No - that's not what I'm saying at all. I'm saying that if you're holding X to a standard, you should hold Y and Z to the same standard.
> No, my users however might need to once they have to deal with a cmake project.
cmake is available from the package manager on basically every system imaginable, or as a binary (or source) download for a whole host of platforms. It's also widely used, so chances are a user is going to have it installed.
> I was told that it takes hours, though I might be misremembering.
If you're going to dogmatically claim that cmake is inferior, then you should at least verify the grounds of your claims are true. I ran
git clone https://github.com/Kitware/CMake.git && cd cmake && cmake -H. -Bbuild && cmake --build build
> This kind of thing does not really distract you from anything. Adding something like that takes as long as it does to add a cmake check. Then the person who is compiling has to do -DENABLE_FEATURE=1.
This isn't unique to cmake but a meta build system does more than just let you add defines.
Re: CMake Part 1 – The Dark Arts
#70Earlier quoted context omitted.
A better solution is to a checkout of your build, then you wont have foo.py and you can be sure you haven't missed anything.
That would work only if you always build after committing all your changes, which is IMHO another anti-pattern.
Er, but OP's tars up and ship after every change?
Get out of here with your antipatterns.