Of all the build systems ever created, #CMake is certainly one of them.
Of all the build systems ever created, #CMake is certainly one of them.
Hmmm… setting
set_source_files_properties(Sourcefile.mm PROPERTIES COMPILE_FLAGS "-fobjc-arc")
for each file seems to fix the issue, though now I’m getting a link error on Swift. Anyway, on to the next error, I guess.
OK, I'm trying to build some mixed C++, ObjC and Swift code with CMake (CLion).
Since the Xcode generator doesn’t seem to work with Swift anymore, I switched over to Ninja, and now all ObjC files are built without ARC.
How do I tell CMake with Ninja to build ObjC(++) files with ARC, but not Swift files??
Mini-rant ahead:
I'm delving into #cmake to try to make it build a compile_commands.json
file to work with #retrocomputing C header files, specifically the #Psion 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 ~/dosbox/sibo-c/SIBOSDK/include/
.
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. #Watcom) to make it behave correctly?
The #github repository of my #sega #mastersystem and #gamegear #emulator called "Masterlator" is now public I've rewritten the code in proper C++, use #cmake as the build system, utilize #sdl2 and added a new #debugger with #wladx compatible *.sym file support, memory viewer and tile/sprite viewer. It's rather basic now but will hopefully be a good tool for #homebrew game #development in the future.
I’m using #CMake in anger for the first time, and to put it mildly I’m not impressed. CMake feels like a pile of workarounds on top of a flimsy foundation made of bad decisions. There’s no logic to it that I can see, only random inconsistent language constructs, names and idioms. Documentation is actively user-hostile. I never thought I’d miss working with #Bazel, but here we are.
Ok. I am very bad at unit tests. I would like to create some. This is on #macos; we use #cmake for the most part, and the #gtest suite for tests, but I'm ok if I can only make something for #xcode
One issue I don't understand is: in Swift, if I want to use a substitute class for a system one (specifically, NEAppProxyFlow and its subclasses)... how do I handle that? Do I provide my own module "NetworkExtension" for the unit tests? Or something else?
From 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 https://www.linux-magazine.com/Issues/2024/280/vcpkg
#vpkg #GitHub #OpenSource #CMake #libraries #PackageManager
cmake for Python 3.29.0 is out now! First release to use scikit-build-core internally as the build backend, Python 3.7+ required. https://github.com/scikit-build/cmake-python-distributions/releases/tag/3.29.0.1 #release #python #cmake
My periodic request for help with fastlane match, cmake, and macos, and (ideally) circleci.
What I need is just enough outside the documentation boxes to make it hard for me to figure out how to do things. I'm willing to pay some amount out of pocket for this.
#Docker users, do you keep Dockerfiles around that might be useful later? If so, where? How do you organise them?
Context: I had a longish Dockerfile I created while debugging something that is reasonable documentation of how to build a #CMake project with lots of dependencies. It's no longer useful on its own.
Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems!
Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!
They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).
Ok, no #scons yet, didn't need it so far
I don’t get why so many package managers use weird, wrong, or ambiguous file extensions for their depencency list file.
Package.swift
CMakeLists.txt
Podfile
How is anyone supposed to build a good client GUI app for them that associates with that file?
Just because a Package.swift happens to be parseable as swift code doesn't mean it shouldn’t have its own .swiftpm extension or so.
Anyone have a working CLion CMake project that builds mixed C++/Swift code?
My Swift has broken. I have a valid toolchain, but CMake says "no CMAKE_Swift_COMPILER could be found". When I look in the .log file, it seems to have success building the SwiftCompilerId thing, so no useful info there either.
Also did a brew upgrade cmake and Software Update doesn't have a command line tools update either, and xcode-select is giving the right Xcode, too.