Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Introduction to Modern CMake

cliutils.gitlab.io

Post reply on HN
Print view View original

61–70 of 126 posts

Re: An Introduction to Modern CMake

#61

Post by tom_ »

nwmcsween wrote: post #43
tom_ wrote: post #29

Earlier quoted context omitted.

What does it require over and above what you'd need for development anyway? The vagrant provision script for my Ubuntu VM installs this lot before grabbing the CMake source and building it: apt-get -y install subversion git make gcc g++ subversion emacs git-gui zip gksu synaptic gdb valgrind I'm pretty sure that not all of these are actually required. You do need gcc and g++, I'm sure, but I expect Valgrind and GDB a…

Gentoo lists: app-crypt/rhash >=app-arch/libarchive-3.0.0:= >=dev-libs/expat-2.0.1 >=dev-libs/libuv-1.10.0:= >=net-misc/curl-7.21.5[ssl] sys-libs/zlib virtual/pkgconfig emacs? ( virtual/emacs ) system-jsoncpp? ( >=dev-libs/jsoncpp-0.6.0_rc2:0= ) of which most have dependencies as well which is honestly ridiculous for a build system.

Perhaps they configured it that way? Maybe these are optional dependencies that provide additional functionality.

I was able to build it on a Ubuntu VM after installing no more than gcc, g++ and make.

apt list --installed suggests this VM does have a surprising amount of stuff installed (more than I'd expected at any rate), but of the dependencies you list it appears to have zlib, curl, and nothing else.

Re: An Introduction to Modern CMake

#62

Post by mr337 »

lilott8 wrote: post #11
mr337 wrote: post #6

This is quite welcoming. I have tried to digest cmake docs and get so lost. Am I the only one that can’t grok cmake docs? Edit: spelling fixes

The only way I've been able to make any sense of CMake docs is in conjunction with examples -- searching on Github/enormous open source projects using it (e.g. LLVM). Just reading CMake docs to understand how to use directive x almost always leads to failure.

Yup agree, I’m like I know this X project compiles file, let me Look at their cmake file....copy pasta.

I’m not proud of it, but it works.

Re: An Introduction to Modern CMake

#63

Post by therein »

goalieca wrote: post #51
orf wrote: post #48

Earlier quoted context omitted.

Maybe we need a language that compiles down to CMake!

Well call it autocmake!

Love it. You start with AutoCMakeLists.m4. Yes, m4 macros are back in the game again!

Using autocmake, you build that into a CMakeLists.txt. After that now you can use cmake to generate your Makefile. Voila.

Re: An Introduction to Modern CMake

#64

Post by kabdib »

matheusmoreira wrote: post #49
kabdib wrote: post #47

Earlier quoted context omitted.

For a domain-specific language, CMAKE is a total failure at making things clearer and simpler and more reliable. And of course the wizened software engineer in me has to be restrained: "Oh hey, I can make a better build system than that..."

Why restrain oneself from starting an interesting project?

The world is full of interesting projects, and you have to do triage or go crazy with too many things to work on. While I have a fair amount of experience with build systems (starting with a public domain version of make that I wrote in the early 1980s for Vax/VMS and MSDOS), it's not something that I want to spend a couple years on.

On the other hand, I complain enough about CMake, Gradle and similar tools that maybe I should. I've got some ideas to try out . . . . :-)

Re: An Introduction to Modern CMake

#65

Post by slavik81 »

LVB wrote: post #56
twic wrote: post #18

Earlier quoted context omitted.

I've been recommended Boost.Build, aka b2, the build system Boost uses to build itself, but also usable for any other project: https://boostorg.github.io/build/manual/develop/

Beware! At a previous job, Boost Build was easily one of the most unpopular aspects of the tech stack. It had 5% of people evangelizing it, and they were also the only ones who “got” the complicated Jam file arrangement. The rest of us couldn’t stand it. Just way too abstruse IMHO.

I used Boost Build for years, but I never figured out how to do anything but copy/paste our existing build files. I found scraps of documentation on Jam here and there, but it never made much sense when I looked at our code. I later discovered CMake and found it much, much easier to learn.

On an unrelated note, the best comment I have ever come across is related to Boost Build: https://github.com/openembedded/openembedded/blob/fabd8e6d07...

Re: An Introduction to Modern CMake

#66

Post by nwmcsween »

tom_ wrote: post #61
nwmcsween wrote: post #43

Earlier quoted context omitted.

Gentoo lists: app-crypt/rhash >=app-arch/libarchive-3.0.0:= >=dev-libs/expat-2.0.1 >=dev-libs/libuv-1.10.0:= >=net-misc/curl-7.21.5[ssl] sys-libs/zlib virtual/pkgconfig emacs? ( virtual/emacs ) system-jsoncpp? ( >=dev-libs/jsoncpp-0.6.0_rc2:0= ) of which most have dependencies as well which is honestly ridiculous for a build system.

Perhaps they configured it that way? Maybe these are optional dependencies that provide additional functionality. I was able to build it on a Ubuntu VM after installing no more than gcc, g++ and make. apt list --installed suggests this VM does have a surprising amount of stuff installed (more than I'd expected at any rate), but of the dependencies you list it appears to have zlib, curl, and nothing else.

Gentoo gives 'use' flags for configurable options, I stripped those out and posted the hard dependencies.

Re: An Introduction to Modern CMake

#67

Post by matheusmoreira »

kabdib wrote: post #64
matheusmoreira wrote: post #49

Earlier quoted context omitted.

Why restrain oneself from starting an interesting project?

The world is full of interesting projects, and you have to do triage or go crazy with too many things to work on. While I have a fair amount of experience with build systems (starting with a public domain version of make that I wrote in the early 1980s for Vax/VMS and MSDOS), it's not something that I want to spend a couple years on. On the other hand, I complain enough about CMake, Gradle and similar tools that mayb…

It'd be nice to see those ideas realized. I have some ideas myself but haven't started anything yet because I've been focusing on my studies. I already have one small project that I work on in my free time.

My problem with most build systems is they're general purpose tools. I need to teach them how my projects work every single time. It'd be so much nicer if I could encode my conventions on the system itself.

Starting a new project should be as easy as initializing a git repository and putting the right files in the right directories. The build system should be able to at least figure out where the sources are based on convention and determine the dependencies between files.

Re: An Introduction to Modern CMake

#68

Post by nwmcsween »

Sir_Cmpwn wrote: post #58

I think the best advice I can give to someone learning about cmake is to use meson instead. I once had dozens of codebases using cmake, and have since moved most of them to meson and start most new new projects with meson.

I dislike meson, it mixes configuration with generation when a separate project (if even really needed as sh is fine) for configuration could exist.

Re: An Introduction to Modern CMake

#70

Post by flukus »

therein wrote: post #63
goalieca wrote: post #51

Earlier quoted context omitted.

Well call it autocmake!

Love it. You start with AutoCMakeLists.m4. Yes, m4 macros are back in the game again! Using autocmake, you build that into a CMakeLists.txt. After that now you can use cmake to generate your Makefile. Voila.

I'll create the root makefile that invokes AutoCMake, then CMake, then Make and then all the edge cases CMake can't handle, plus add a much more usable interface.... Take out AutoCMake and it's actually what I'm doing right now.

> Yes, m4 macros are back in the game again!

Actually, I did some codegen experiments recently and found M4 to be really nice once you get past the bad documentation and actually understand it, along with ignoring any experiences with autotools of course. Besides the general substitutions and macros, the divert/undivert primitives are simple yet this is where the real power of the language is, they easily let you write to a number of named/numbered buffers and then pull them back in where needed. The wikipedia article probably shows this off more clearly than the documentation: https://en.wikipedia.org/wiki/M4_(computer_language)

Post reply on HN