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

121–126 of 126 posts

Re: An Introduction to Modern CMake

#121

Post by DoofusOfDeath »

DoofusOfDeath wrote: post #101
overgard wrote: post #71

It’s better than every other build system, but god I wish they had just used a preexisting language for it. The syntax for CMake just feels so janky and weird, and it’s another set of things I have to remember and (eventually) forget. It’s not like it has these amazing language concepts nothing else can do; and if they’re worried about size or dependencies something like Lua would add like no overhead and be super si…

I agree. CMake's scripting language has a lot of the same pain-points as Bash. For example, the lack of a clear distinction between lists and strings. I've sometimes wondered if CMake would benefit from getting an additional / replacement scripting language. While retaining the same underlying object model and other code, that is. My only fear would be that it would be a first step in morphing into Bazel, which I fin…

Clarification: I know that Bash has arrays. But environment variables such as "PATH" use colon-separated strings.

Re: An Introduction to Modern CMake

#122

Post by flukus »

enriquto wrote: post #99
flukus wrote: post #70

Earlier quoted context omitted.

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 i…

> found M4 to be really nice once you get past the bad documentation The gnu m4 manual is one of my favourite technical documents, what's wrong with it?

Like most gnu projects, the manual is very good, the problem is it's a manual and just a reference for looking up specific things, it doesn't really explain how to use m4. I'm not sure if this is by design or lack of effort in that direction.

Take divert for instance like a mentioned above, it's one of the foundations that make m4 good but it's not mentioned until chapter 10 and even then the examples are hard to follow and not particularly good, they could have gone with something more real world:

    define(INDEX, 1)
    define(BODY, 2)
    define(ADD_CHAPTER, heading, text
      divert(INDEX)
      heading
      divert(BODY)
      heading
      text
    )

    #guts of the generation go here
    ADDCHAPTER('one', 'paragraph one')
    ADDCHAPTER('two', 'paragraph two')

    undivert(INDEX)
    unidvert(BODY)
The syntax there isn't correct, but I think an example like that shows off how and why you'd use this feature more than the examples in the documentation.

Re: An Introduction to Modern CMake

#123

Post by gnufx »

Shorel wrote: post #97
baby wrote: post #8

Earlier quoted context omitted.

This syntax is also uber ugly. I can’t understand why C still hasn’t a proper build system that is either using convention over configuration (like Go or Rust) or something like cmake but with a proper syntax (maybe something in pyhon?)

Before CMake the "proper" thing were ./configure and ./automake scripts which are an atrocity from any point of view. More than "proper", or simply "nice looking syntax" the thing I like from CMake is that a single file makes my project compile in several versions of Linux and Windows using a variety of compilers. Any suitable replacement system should also do this.

To me autotools have the great advantage that I can make projects using them work relatively easily if they need adjusting in one of the many things I build, and I can write the support for a new project easily. They're pragmatic, and I don't think deserve "atrocity" by any means. In contrast, cmake often causes me to throw up my hands. It's not my experience that cmake projects just work even on GNU/Linux when needing, say, to build shared libraries or install in a different sort of tree. I've used autotools quite painlessly over many years on assorted platforms including in GCC "Canadian cross" (cross-building a cross-compiler -- between GNU/Linux, SunOS, and MS-DOS originally). I did find a new level of horror in bazel when faced with building tensorflow for a different target, despite explicit instructions for a different release.

Re: An Introduction to Modern CMake

#124

Post by whyever »

rutthenut wrote: post #100
whyever wrote: post #95

Earlier quoted context omitted.

It's kind of a historical accident. Originally, CMake was supposed to be just a list of commands (CMakeLists.txt). Of course, it was heavily extended to what we have now.

Do understand that things change over time, from simple beginnings to complex offspring. But I agree with many commenters here; it is frustrating and a ball-ache to have to learn yet another syntax to manage build dependencies and instructions. On that, I also detest how YAML, Python and so on make space indentation a core aspect of how the files are interpreted and processed. That idea stinks. imvho.

> it is frustrating and a ball-ache to have to learn yet another syntax to manage build dependencies and instructions.

Oh, I agree as well. I was just providing context.

Re: An Introduction to Modern CMake

#125

Post by geofft »

superkuh wrote: post #55
IshKebab wrote: post #17

Earlier quoted context omitted.

A nice tip is that you can install a very recent CMake from pip with most systems. Just `pip install cmake` and then you can require version 3.12 and don't have to worry about ancient Ubuntu packages or whatever.

On systems were you don't need to do this (new enough) it'll work. On systems where you need to do this it will break things. And because it's pip, it'll be incredibly hard to figure out what broke and how to fix it.

In general you can avoid pip breaking things by doing so inside a virtualenv. The following should work on at least the last few years' worth of OSes:

    $ virtualenv /tmp/ve
    $ /tmp/ve/bin/pip install -U pip setuptools
    $ /tmp/ve/bin/pip install cmake
    $ /tmp/ve/bin/cmake ...
    $ rm -rf /tmp/ve
On some OSes (e.g. Debian and derivatives) you'll need to install virtualenv itself from the OS first, but that won't break things because it's from the OS.

On sufficiently old OSes, you may need to set PIP_INDEX_URL=https://pypi.org/simple/ and PIP_TRUSTED_HOST="pypi.org files.pythonhosted.org" to disable certificate verification. (I'm not sure of a good way to work around this problem. In theory, Python 3 would solve it, but those same old OSes have an old enough Python 3 that the latest version of setuptools fails, and I can't figure out how to install an old enough setuptools.)

Also - if you need to unbreak your system Python, in general it suffices to ensure that /usr/local/lib and ~/.local/lib have no pythonX.Y directories with anything in them. (Empty directories are fine.) At my last job where we needed to give non-sysadmins root access on certain machines, I added a Nagios check to /usr/local/lib/python*, which was remarkably effective at catching problems before they turned inexplicable.

Re: An Introduction to Modern CMake

#126

Post by Shorel »

gnufx wrote: post #123
Shorel wrote: post #97

Earlier quoted context omitted.

Before CMake the "proper" thing were ./configure and ./automake scripts which are an atrocity from any point of view. More than "proper", or simply "nice looking syntax" the thing I like from CMake is that a single file makes my project compile in several versions of Linux and Windows using a variety of compilers. Any suitable replacement system should also do this.

To me autotools have the great advantage that I can make projects using them work relatively easily if they need adjusting in one of the many things I build, and I can write the support for a new project easily. They're pragmatic, and I don't think deserve "atrocity" by any means. In contrast, cmake often causes me to throw up my hands. It's not my experience that cmake projects just work even on GNU/Linux when needi…

You should write an article detailing your experience with both systems.

It should make for an interesting read.

Post reply on HN