#cmake

oblateI have a long-standing project which I am converting to use C++ modules. I've decided that using <a href="https://mastodon.social/tags/perl" class="mention hashtag" rel="nofollow noopener" target="_blank">#perl</a> to generate the Makefile is vastly easier than using <a href="https://mastodon.social/tags/autotools" class="mention hashtag" rel="nofollow noopener" target="_blank">#autotools</a> and <a href="https://mastodon.social/tags/cmake" class="mention hashtag" rel="nofollow noopener" target="_blank">#cmake</a>. At least I can understand WTF is going on.In the end, programmatical beats automagical.

Matěj Cepl 🇪🇺 🇨🇿 🇺🇦<a href="https://social.treehouse.systems/@mgorny" class="u-url mention" rel="nofollow noopener" target="_blank">@mgorny</a> I wanted to say that “of course, <a href="https://en.osm.town/tags/openSUSE" class="mention hashtag" rel="nofollow noopener" target="_blank">#openSUSE</a> uses <a href="https://en.osm.town/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a>, because we do The Right Thing™”, but then I had a look at our SPEC <a href="https://build.opensuse.org/projects/openSUSE:Factory/packages/hdf5/files/hdf5.spec?expand=1" rel="nofollow noopener" translate="no" target="_blank">https://build.opensuse.org/projects/openSUSE:Factory/packages/hdf5/files/hdf5.spec?expand=1</a> … yes, we use CMake, but that’s A LOT of hand-waving around it to make it work!

mgorny-nyan (he) :autism:🙀🚂🐧<a href="https://social.treehouse.systems/tags/HDF5" class="mention hashtag" rel="nofollow noopener" target="_blank">#HDF5</a> is doing great. So basically:1. Originally, upstream used autotools. The build system installed a h5cc wrapper which — besides being a compiler wrapper — had a few config-tool style options. 2. Then, upstream added <a href="https://social.treehouse.systems/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a> build system as an alternative. It installed a different h5cc wrapper that did not have the config-tool style options anymore. 3. Downstreams that tried CMake quickly discovered that the new wrapper broke a lot of packages, so they reverted to autotools and reported a bug. 4. Upstream closed the bug, handwaving it as "CMake h5cc changes have been noted in the Release.txt at the time of change - archived copy should exist in the history files." 5. Upstream announced the plans to remove autotools support.So, to summarize the current situation:1. Pretty much everyone (at least <a href="https://social.treehouse.systems/tags/Arch" class="mention hashtag" rel="nofollow noopener" target="_blank">#Arch</a>, <a href="https://social.treehouse.systems/tags/Conda" class="mention hashtag" rel="nofollow noopener" target="_blank">#Conda</a>-forge, <a href="https://social.treehouse.systems/tags/Debian" class="mention hashtag" rel="nofollow noopener" target="_blank">#Debian</a>, <a href="https://social.treehouse.systems/tags/Fedora" class="mention hashtag" rel="nofollow noopener" target="_blank">#Fedora</a>, <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#Gentoo</a>) is building using autotools, because CMake builds cause too much breakage. 2. Downstreams originally judged this to be a HDF5 issue, so they didn't report bugs to affected packages. Not sure if they're even aware that HDF5 upstream rejected the report. 3. All packages remain "broken", and I'm guessing their authors may not even be aware of the problem, because, well, as I pointed out, everyone is still using autotools, and nobody reported the issues during initial CMake testing. 4. I'm not even sure if there is a good "fix" here. I honestly don't know the package, but it really sounds like the config-tool was removed with no replacement, so the only way forward might be for people to switch over to CMake (sigh) — which would of course break the packages almost everywhere, unless people also add fallbacks for compatibility with autotools builds. 5. The upstream's attitude suggests that HDF5 is pretty much a project unto itself, and doesn't care about its actual users.<a href="https://github.com/HDFGroup/hdf5/issues/1814" rel="nofollow noopener" translate="no" target="_blank">https://github.com/HDFGroup/hdf5/issues/1814</a>

The Last Psion | AlexMini-rant ahead:I'm delving into <a href="https://oldbytes.space/tags/cmake" class="mention hashtag" rel="nofollow noopener" target="_blank">#cmake</a> to try to make it build a <code>compile_commands.json</code> file to work with <a href="https://oldbytes.space/tags/retrocomputing" class="mention hashtag" rel="nofollow noopener" target="_blank">#retrocomputing</a> C header files, specifically the <a href="https://oldbytes.space/tags/Psion" class="mention hashtag" rel="nofollow noopener" target="_blank">#Psion</a> SIBO C SDK (from the early 90s).I don't actually want cmake to do anything but tell clangd what to do, so that I've got a working language server in NeoVim.I don't need it to build any Makefiles, I don't need it to tell a compiler what to do. I just want clangd to treat my old 16-bit real mode code correctly, and that the header files are in <code>~/dosbox/sibo-c/SIBOSDK/include/</code>.Note that I can't point it at the compiler, because the compiler (TopSpeed) runs in DOSBox. There is no modern compiler that will work.So... Do I have to fake it somehow? For example, do I have to tell cmake that it's actually using a different compiler (e.g. <a href="https://oldbytes.space/tags/Watcom" class="mention hashtag" rel="nofollow noopener" target="_blank">#Watcom</a>) to make it behave correctly?

RetoKenntnisse im Umgang mit dem "CMake Compiler"Das is bestimmt ein Traumjob. 🙃<a href="https://careers.thalesgroup.com/de/de/job/R0263142/Software-Real-Time-Embedded-Engineer-100-m-w-d" rel="nofollow noopener" translate="no" target="_blank">https://careers.thalesgroup.com/de/de/job/R0263142/Software-Real-Time-Embedded-Engineer-100-m-w-d</a><a href="https://swiss.social/tags/FOSS" class="mention hashtag" rel="nofollow noopener" target="_blank">#FOSS</a> <a href="https://swiss.social/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a> <a href="https://swiss.social/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a>

chnThe <a href="https://mastodon.art/tags/github" class="mention hashtag" rel="nofollow noopener" target="_blank">#github</a> repository of my <a href="https://mastodon.art/tags/sega" class="mention hashtag" rel="nofollow noopener" target="_blank">#sega</a> <a href="https://mastodon.art/tags/mastersystem" class="mention hashtag" rel="nofollow noopener" target="_blank">#mastersystem</a> and <a href="https://mastodon.art/tags/gamegear" class="mention hashtag" rel="nofollow noopener" target="_blank">#gamegear</a> <a href="https://mastodon.art/tags/emulator" class="mention hashtag" rel="nofollow noopener" target="_blank">#emulator</a> called "Masterlator" is now public 🙂 I've rewritten the code in proper C++, use <a href="https://mastodon.art/tags/cmake" class="mention hashtag" rel="nofollow noopener" target="_blank">#cmake</a> as the build system, utilize <a href="https://mastodon.art/tags/sdl2" class="mention hashtag" rel="nofollow noopener" target="_blank">#sdl2</a> and added a new <a href="https://mastodon.art/tags/debugger" class="mention hashtag" rel="nofollow noopener" target="_blank">#debugger</a> with <a href="https://mastodon.art/tags/wladx" class="mention hashtag" rel="nofollow noopener" target="_blank">#wladx</a> compatible *.sym file support, memory viewer and tile/sprite viewer. It's rather basic now but will hopefully be a good tool for <a href="https://mastodon.art/tags/homebrew" class="mention hashtag" rel="nofollow noopener" target="_blank">#homebrew</a> game <a href="https://mastodon.art/tags/development" class="mention hashtag" rel="nofollow noopener" target="_blank">#development</a> in the future.<a href="https://github.com/chn-dev/MasterlatorSDL/" rel="nofollow noopener" translate="no" target="_blank">https://github.com/chn-dev/MasterlatorSDL/</a><a href="https://www.chn-dev.net/Projects/Masterlator/" rel="nofollow noopener" translate="no" target="_blank">https://www.chn-dev.net/Projects/Masterlator/</a>

Ludovic CourtèsDid it find it or did it not?<a href="https://toot.aquilenet.fr/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a> ❤

Linux MagazineFrom the Linux Update newsletter: If you're looking for a C/C++ package manager, learn about Microsoft's platform-independent vcpkg for managing libraries and their dependencies <a href="https://www.linux-magazine.com/Issues/2024/280/vcpkg" rel="nofollow noopener" translate="no" target="_blank">https://www.linux-magazine.com/Issues/2024/280/vcpkg</a> <a href="https://fosstodon.org/tags/vpkg" class="mention hashtag" rel="nofollow noopener" target="_blank">#vpkg</a> <a href="https://fosstodon.org/tags/GitHub" class="mention hashtag" rel="nofollow noopener" target="_blank">#GitHub</a> <a href="https://fosstodon.org/tags/OpenSource" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenSource</a> <a href="https://fosstodon.org/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a> <a href="https://fosstodon.org/tags/libraries" class="mention hashtag" rel="nofollow noopener" target="_blank">#libraries</a> <a href="https://fosstodon.org/tags/PackageManager" class="mention hashtag" rel="nofollow noopener" target="_blank">#PackageManager</a>

technomancyI'm not like ... a frequent contributor to <a href="https://hey.hagelb.org/tags/tic80" class="mention hashtag" rel="nofollow noopener" target="_blank">#tic80</a>; I submit patches maybe once or twice a yearthat said, ever since my first contribution, I can't remember a SINGLE time I've pulled down the latest main and had it actually build successfully; every single time, <a href="https://hey.hagelb.org/tags/cmake" class="mention hashtag" rel="nofollow noopener" target="_blank">#cmake</a> finds some new way to screw things uptoday after working thru some bullshit I finally got it to build successfully, but my build knows no languages despite me passing the cmake flag to build all languages

Harry Sintonen<a href="https://infosec.exchange/tags/GCC14" class="mention hashtag" rel="nofollow noopener" target="_blank">#GCC14</a> promoted some warnings to errors. This can break <a href="https://infosec.exchange/tags/autoconf" class="mention hashtag" rel="nofollow noopener" target="_blank">#autoconf</a>, <a href="https://infosec.exchange/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a>, <a href="https://infosec.exchange/tags/Meson" class="mention hashtag" rel="nofollow noopener" target="_blank">#Meson</a> or other build environments autoprobing for features, resulting in code built with missing or altered functionality. This could even lead to security impact, if some security related feature is unexpectedly not enabled.Passing CC as "gcc -fpermissive" should fix this. If this is not an option there's even the nuclear option of adding a gcc wrapper script that does:#!/bin/sh exec /usr/bin/gcc -fpermissive "$@"EDIT: I do not mean to say that these new options should blanket-disabled globally. There however are currently some packages that have problems with GCC 14 (missing features or existing functions not being used, or just failing to build). Naturally these packages should be fixed themselves. Meanwhile -fpermissive will allow building most of these troublesome packages.

RainTechnology/Programs that are black magic to me and I will never understand how to properly use them no matter how bad i want to. (In no special order) - <a class="hashtag" href="https://melonbread.dev/tag/blender" rel="nofollow noopener" target="_blank">#Blender</a> (3D Modeling in general) - <a class="hashtag" href="https://melonbread.dev/tag/cmake" rel="nofollow noopener" target="_blank">#CMake</a> - <a class="hashtag" href="https://melonbread.dev/tag/dwarffortress" rel="nofollow noopener" target="_blank">#DwarfFortress</a> - <a class="hashtag" href="https://melonbread.dev/tag/freecad" rel="nofollow noopener" target="_blank">#freeCAD</a> (or cad in general) - <a class="hashtag" href="https://melonbread.dev/tag/rust" rel="nofollow noopener" target="_blank">#Rust</a>-lang (I can run `cargo install` just fine) - <a class="hashtag" href="https://melonbread.dev/tag/powershell" rel="nofollow noopener" target="_blank">#PowerShell</a> (eh, don't care that I don't get this one) - <a class="hashtag" href="https://melonbread.dev/tag/secureboot" rel="nofollow noopener" target="_blank">#SecureBoot</a> - <a class="hashtag" href="https://melonbread.dev/tag/treafik" rel="nofollow noopener" target="_blank">#Treafik</a> This is probably more but man it kills me I can not wrap my head around these.

Cr0ydonWhen you use <a href="https://mastodon.social/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a> with the Visual Studio Generator and you tell it explicitly BUILD_SHARED_LIBS=ON it will build shared AND static, but if you don't specify this variable it will only build a static build??????????????

Markus Werle<a href="https://hachyderm.io/@Di4na" class="u-url mention" rel="nofollow noopener" target="_blank">@Di4na</a> And now I have to put more work into it because <a href="https://nrw.social/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a> continues (!) to refine how dependencies can me managed. <a href="https://www.youtube.com/watch?v=s0q6s5XzIrA" rel="nofollow noopener" translate="no" target="_blank">https://www.youtube.com/watch?v=s0q6s5XzIrA</a>

Markus Werle<a href="https://hachyderm.io/@Di4na" class="u-url mention" rel="nofollow noopener" target="_blank">@Di4na</a> Nice and efficient build system that are humane to use:Well, this is the topic that most work went into. Look at what happened to <a href="https://nrw.social/tags/CMake" class="mention hashtag" rel="nofollow noopener" target="_blank">#CMake</a> within the past ten years. This is a completely different system now. To catch up I highly recommend Craig Scott's seminal book: <a href="https://crascit.com/professional-cmake/" rel="nofollow noopener" translate="no" target="_blank">https://crascit.com/professional-cmake/</a>In contrast to 2018, I consider CMake now something that humans can use without losing their minds. Some recent changes indicate that the travel is not over:<a href="https://cpp-aachen.github.io/archive/2024-04-10/2024_04_10_CMake_File_Sets.pdf" rel="nofollow noopener" translate="no" target="_blank">https://cpp-aachen.github.io/archive/2024-04-10/2024_04_10_CMake_File_Sets.pdf</a>

Recent searches

Search options

Administered by:

Server stats: