An Introduction to Modern CMake • Hacker News Board

Re: An Introduction to Modern CMake

#91

Post by jcelerier » Mon, Sep 03, 2018, 10:20 AM UTC

gumby wrote: post #30

nerdponx wrote: post #28

Earlier quoted context omitted.

What's wrong with dependencies?

Every dependency increases the fragility of your program. What if you update the dependency and it breaks your program? What if you have two programs dependent on the same library -- but different versions? This just scratches at the surface of the problem. Sometimes the risk is worth it: you need some complex functionality not worth writing yourself. In that case it's a good thing. But understand that it's a tradeof…

> you need some complex functionality not worth writing yourself.

well, CMake supports downloading stuff from the internet - git repositories, etc. If you want to be able to download from https:// addresses I sure hope that you won't reimplement it yourself.

Re: An Introduction to Modern CMake

#92

Post by ur-whale » Mon, Sep 03, 2018, 10:22 AM UTC

tux1968 wrote: post #4

The recommended compatibility boilerplate for new projects is tedious. There must be a way to include this knowledge in cmake itself rather than requiring every "properly" configured project to get this right: cmake_minimum_required(VERSION 3.1) if(${CMAKE_VERSION} VERSION_LESS 3.12) cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}) else() cmake_policy(VERSION 3.12) endif() This is all before you ev…

Worse, if you try to leave those lines out because just seeing them at the start of every build file, the whole ball of spit an glue pesters you with warnings. Ugh.

Re: An Introduction to Modern CMake

#93

Post by ur-whale » Mon, Sep 03, 2018, 10:30 AM UTC

mianos wrote: post #38

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?)

There is a python one, waf, https://en.m.wikipedia.org/wiki/Waf It is awesome but not very popular. I wish it was more popular. As a python and C++ developer the build files and up so much clearer than anything else. I write and use cmake files every day and I don't like it at all.

Interesting, thanks for that.

Haven't dug into it yet to say thumbs up or down, but the fact that it uses a full-fledged generic programming language instead of a DSL is a promising start.

Here's a waf "makefile":

https://gitlab.com/ita1024/waf/blob/master/demos/c++/wscript

Re: An Introduction to Modern CMake

#94

Post by ur-whale » Mon, Sep 03, 2018, 11:01 AM UTC

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…

Couldn't agree more.

Any system that designs its own DSL should be suspect: designing languages is bloody hard, and anyone who think he can cobble his own to solve a problem as hard as build systems is doomed to produce something like cmake.

Re: An Introduction to Modern CMake

#95

Post by whyever » Mon, Sep 03, 2018, 11:45 AM UTC

ur-whale wrote: post #94

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…

Couldn't agree more. Any system that designs its own DSL should be suspect: designing languages is bloody hard, and anyone who think he can cobble his own to solve a problem as hard as build systems is doomed to produce something like cmake.

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.

Re: An Introduction to Modern CMake

#96

Post by vetinari » Mon, Sep 03, 2018, 12:20 PM UTC

simonask wrote: post #81

MrQuincle wrote: post #39

What I find a big shortcoming from CMake is that it does not have support for building for multiple architectures at once. https://cmake.org/pipermail/cmake-developers/2014-September/... Quote: "The fundamental problem with supporting multiple architectures is that pretty much all of CMake is designed to support one architecture at a time. Modules/*, CMakeCache.txt, etc. are all built around only finding, using, and…

CMake replaces `configure` scripts. It would be difficult to imagine what multi-architecture support in a single build directory / command-line invocation would look like. Instead, what we do is to wrap calls to CMake in a script that makes choices about build directories, which flavours to build by default, which mobile SDKs exist, etc. When producing a release, we notably don't use this, because we are precisely in…

> It would be difficult to imagine what multi-architecture support in a single build directory / command-line invocation would look like

That's exactly what MacOS fat binaries are. Single binary contains sections for multiple architectures.

Re: An Introduction to Modern CMake

#97

Post by Shorel » Mon, Sep 03, 2018, 12:32 PM UTC

baby wrote: post #8

tux1968 wrote: post #4

The recommended compatibility boilerplate for new projects is tedious. There must be a way to include this knowledge in cmake itself rather than requiring every "properly" configured project to get this right: cmake_minimum_required(VERSION 3.1) if(${CMAKE_VERSION} VERSION_LESS 3.12) cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}) else() cmake_policy(VERSION 3.12) endif() This is all before you ev…

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.

Re: An Introduction to Modern CMake

#98

Post by jcelerier » Mon, Sep 03, 2018, 12:34 PM UTC

twic wrote: post #18

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?)

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/

Boost.Build is so good that even Boost is moving to CMake

Re: An Introduction to Modern CMake

#99

Post by enriquto » Mon, Sep 03, 2018, 12:36 PM UTC

flukus wrote: post #70

therein wrote: post #63

Earlier quoted context omitted.

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 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?

Re: An Introduction to Modern CMake

#100

Post by rutthenut » Mon, Sep 03, 2018, 12:45 PM UTC

whyever wrote: post #95

ur-whale wrote: post #94

Earlier quoted context omitted.

Couldn't agree more. Any system that designs its own DSL should be suspect: designing languages is bloody hard, and anyone who think he can cobble his own to solve a problem as hard as build systems is doomed to produce something like cmake.

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.