I cobbled together a cmake example (attached). Unpack it in some junk folder and run 'cme.sh'. All it does is a "hello world" and call a routine from a static lib it creates. The takeaway point is it creates a cmake folder hierarchy which you can use a a basis for your own code.
I commented out, (*1) in the zip, the mysql stuff which merely serves as an example of how to reference an external library. It would work if you had a mariadb installed in /usr/local/ (masquerading as mysql) which you won't have because I built mariadb from source. You'd change the MYSQL* stuff to a name which references the dev files for something your project depends on.
Note 'cme.sh' deletes the contents of the build folder "obj" each time you run it. This isn't strictly necessary but as I mentioned last time, cmake has a habit of remembering things. Sometimes what it remembers will prevent it from doing the right thing even if you have fixed "the problem". Not only has cmake evolved over time (making google searches dodgy) but it's cross-platform and is a programming language in its own right. It may help to use an IDE which can import "CMakeLists.txt". I use QtCreator for instance. An IDE can give an overview and may yield hints on a broken CMakeLists.txt (eg: you change a file and nothing recompiles). Ultimately though, you aim toward building the project entirely from the command line.
Cmake is a pig wearing lipstick. That's an improvement over the "autotools" which were multiple pigs wearing unherdable cat suits. Even the venerable old "makefile" gets shoved out the airlock if cmake senses a ninja in the room. Image may be NSFW.
Clik here to view.
Seems my time is up. I hope the difference between last post and this zip aids understanding.
I commented out, (*1) in the zip, the mysql stuff which merely serves as an example of how to reference an external library. It would work if you had a mariadb installed in /usr/local/ (masquerading as mysql) which you won't have because I built mariadb from source. You'd change the MYSQL* stuff to a name which references the dev files for something your project depends on.
Note 'cme.sh' deletes the contents of the build folder "obj" each time you run it. This isn't strictly necessary but as I mentioned last time, cmake has a habit of remembering things. Sometimes what it remembers will prevent it from doing the right thing even if you have fixed "the problem". Not only has cmake evolved over time (making google searches dodgy) but it's cross-platform and is a programming language in its own right. It may help to use an IDE which can import "CMakeLists.txt". I use QtCreator for instance. An IDE can give an overview and may yield hints on a broken CMakeLists.txt (eg: you change a file and nothing recompiles). Ultimately though, you aim toward building the project entirely from the command line.
Cmake is a pig wearing lipstick. That's an improvement over the "autotools" which were multiple pigs wearing unherdable cat suits. Even the venerable old "makefile" gets shoved out the airlock if cmake senses a ninja in the room. Image may be NSFW.
Clik here to view.
Seems my time is up. I hope the difference between last post and this zip aids understanding.
Statistics: Posted by swampdog — Thu May 23, 2024 7:04 pm
