5 ms·

> Most part of my career I used Visual Studio and when switched to Linux I was slightly shocked. Compared to MSVS, makefiles felt like bows and arrows against m

> Most part of my career I used Visual Studio and when switched to Linux I was slightly shocked. Compared to MSVS, makefiles felt like bows and arrows against machine gun. I honesty have no idea how some people come up with these absurd comparisons. I mean, who in their right mind feel is appropriate to compare a Makefile with a build system? And how clueless about things are "in the Linux world" do you need to be to claim that Makefiles are how people build software in Linux? I mean, I've been using Linux for a couple of decades now and I can't remember the last time I saw a project that relied on Makefiles to build. At best projects use some kind of Makefile generator. The ancient ones use autotools and even those are going the way of the dodo. > CMake allows us to handle almost all those things right except one - it doesn’t have return values This is a red flag. If you're hoping to write functions with cmake... You're doing it wrong. Very wrong. You add targets, and you add rules to the target. If you find yourself wanting to do anything other than this then you should take a step back and read a modern cmake tutorial again, because odds are you're doing it wrong.

dlivingston 6y ago
> I've been using Linux for a couple of decades now and I can't remember the last time I saw a project that relied on Makefiles to build. Makefiles, at least in my corner of the industry, are exceedingly common for projects with a build process of medium-to-low complexity.
sebastos 6y ago
Link to a free and open modern cmake tutorial?
- rumanator 6y ago
  You can pretty much google for "modern cmake tutorial" to get a long list of tutorials on how to write target-based cmake projects.
  - moonbug 6y ago
    spoiler: they're all crap.
    - nickez 6y ago
      And worse, they all achieve the same goal in different ways...
      - mlvljr 6y ago
        Not to mention, target outdated ways of doing things with CMake (there is always 3-4 at least).
      - MaxBarraclough 6y ago
        A great point. There should a single standard and well-documented way to do things. The documentation should be official, the user should not be expected to trawl the blogosphere and piece together the knowledge they need. There should be plenty of complete examples. Ideally the official Find... packages should not make use of deprecated CMake functionality, they should be actively maintained to follow the current best-practices, so that they can serve as examples of the right way to do it. As I rambled about in my longer comment yesterday, this kind of work shouldn't require you to think, it should just be an exercise in applying boring, samey, dependable boilerplate.
  - sebastos 6y ago
    https://cliutils.gitlab.io/modern-cmake/chapters/basics.html https://cliutils.gitlab.io/modern-cmake/chapters/basics.html ^ Is that a good one?
1ris 6y ago
I would love to use makefiles and git submodules instead of this msbuild/nuget contraption. That would be way less sophisticated, but I would welcome it. msbuild seems like a good example of microsofts tendency to overengineer simple things. But sometimes its suprisingly simple. different build configuration are just strings stiched together like "x64|Debug", and then are are conditionals to that value. Msbuild it's kind of a CLR language, but you can't debug it. The xml sytax and the syntax you use in the attributes feels arkward but sometimes limited for no good reason. Is <Message Text="Backup files: @(Compile->'%(filename).bak')" /> what i would want, if I'm used to linq? No, not me. @ and % are not intuitive for me. I usually have to try out what works. Accessing members of objects is odd. Calling System.String.Format feels like I'm supposed to do it. Anything interesting has to be done with custom task, and these are hard to debug aswell. For example studio would unload the .dlls, so you have to close it every time. That thing feels like a classic turing tarpit. A very complicated turing tarpit. Then again, if your build should output a .nupkg, the whole infrastructure seems to be lacking. You are left alone doing things that seem like they should be part of a package manager. e.g. handling of the version number. The whole build system knows the build output, but you have to specify it by hand again, in a different file.
deleted 6y ago
[deleted]
kazinator 6y ago
> I can't remember the last time I saw a project that relied on Makefiles to build I don't know what GNU/Linux you're using, because in my experience, most packages going into a distro use make. Oh, and then there is that whole denominator in the GNU/Linux fraction that's built with GNU Make. Maybe you don't see Makefiles because you're relying on binary packages?
- jcelerier 6y ago
  > I don't know what GNU/Linux you're using, because in my experience, most packages going into a distro use make. no, they use autotools or cmake, which happens to generate makefiles. the package authors themselves definitely don't write any makefiles by hand except maybe for trivial packages (and frankly I'm not sure)
  - kazinator 6y ago
    Autotools generate a Makefile project, and nothing but a Makefile project. All the buiding in the development cycle is done by typing "make". Autotools projects include a template makefile: Makefile.am. Make is not concealed in any way. Also note that not all Autotools-based projects use Automake. Using only Autoconf, with a hand-maintained Makefile, is a thing. The goal of Autotools is to produce a software distribution that doesn't require the end user to have Autotools. The end user has a shell to run the configure script, and that's it. If that works, they run "make". About the most sophisticated generation the user will see is that some Makefile.in template is passed through sed to substitute @@XYZ@@ variables.
    - anand-bala 6y ago
      This is true for Autotools projects, but isn't true for CMake, Bazel, Meson, and others. Let's take CMake for example, which is IMHO the most popular build tool: most modern CMake projects prefer to use the Ninja build system over Make. And coming back to Autotools, some of the largest Autotools projects (see the GNOME ecosystem) has been moving/moved to Meson, which can also be used to generate Ninja rules instead of Makefiles. CMake Generators: https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html https://cmake.org/cmake/help/latest/manual/cmake-generators.... Meson: https://mesonbuild.com/ https://mesonbuild.com/ Bazel: https://bazel.build/ https://bazel.build/ GNOME and Meson: https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
bluGill 6y ago
I use modern cmake as much as I can, but I often run into things that cmake cannot do without a function. Most of our custom code generation tools for example, cmake doesn't know how to turn them into c++ without a function (which is in turn a wrapper of add custom command /target I've gotten rid of several of our pre modern cmake functions, but more remain.
jcelerier 6y ago
> This is a red flag. If you're hoping to write functions with cmake... You're doing it wrong. Very wrong. You add targets, and you add rules to the target. If you find yourself wanting to do anything other than this then you should take a step back and read a modern cmake tutorial again, because odds are you're doing it wrong. so how do you propose to do code generation, parsing stuff like /etc/lsb_release to work around a bug for people building under ubuntu 16.04, or that kind of thing ?

dlivingston 6y ago

> I've been using Linux for a couple of decades now and I can't remember the last time I saw a project that relied on Makefiles to build. Makefiles, at least in my corner of the industry, are exceedingly common for projects with a build process of medium-to-low complexity.

sebastos 6y ago

Link to a free and open modern cmake tutorial?

rumanator 6y ago
You can pretty much google for "modern cmake tutorial" to get a long list of tutorials on how to write target-based cmake projects.
- moonbug 6y ago
  spoiler: they're all crap.
  - nickez 6y ago
    And worse, they all achieve the same goal in different ways...
    - mlvljr 6y ago
      Not to mention, target outdated ways of doing things with CMake (there is always 3-4 at least).
    - MaxBarraclough 6y ago
      A great point. There should a single standard and well-documented way to do things. The documentation should be official, the user should not be expected to trawl the blogosphere and piece together the knowledge they need. There should be plenty of complete examples. Ideally the official Find... packages should not make use of deprecated CMake functionality, they should be actively maintained to follow the current best-practices, so that they can serve as examples of the right way to do it. As I rambled about in my longer comment yesterday, this kind of work shouldn't require you to think, it should just be an exercise in applying boring, samey, dependable boilerplate.
- sebastos 6y ago
  https://cliutils.gitlab.io/modern-cmake/chapters/basics.html https://cliutils.gitlab.io/modern-cmake/chapters/basics.html ^ Is that a good one?

1ris 6y ago

I would love to use makefiles and git submodules instead of this msbuild/nuget contraption. That would be way less sophisticated, but I would welcome it. msbuild seems like a good example of microsofts tendency to overengineer simple things. But sometimes its suprisingly simple. different build configuration are just strings stiched together like "x64|Debug", and then are are conditionals to that value. Msbuild it's kind of a CLR language, but you can't debug it. The xml sytax and the syntax you use in the attributes feels arkward but sometimes limited for no good reason. Is <Message Text="Backup files: @(Compile->'%(filename).bak')" /> what i would want, if I'm used to linq? No, not me. @ and % are not intuitive for me. I usually have to try out what works. Accessing members of objects is odd. Calling System.String.Format feels like I'm supposed to do it. Anything interesting has to be done with custom task, and these are hard to debug aswell. For example studio would unload the .dlls, so you have to close it every time. That thing feels like a classic turing tarpit. A very complicated turing tarpit. Then again, if your build should output a .nupkg, the whole infrastructure seems to be lacking. You are left alone doing things that seem like they should be part of a package manager. e.g. handling of the version number. The whole build system knows the build output, but you have to specify it by hand again, in a different file.

deleted 6y ago

[deleted]

kazinator 6y ago

> I can't remember the last time I saw a project that relied on Makefiles to build I don't know what GNU/Linux you're using, because in my experience, most packages going into a distro use make. Oh, and then there is that whole denominator in the GNU/Linux fraction that's built with GNU Make. Maybe you don't see Makefiles because you're relying on binary packages?

jcelerier 6y ago
> I don't know what GNU/Linux you're using, because in my experience, most packages going into a distro use make. no, they use autotools or cmake, which happens to generate makefiles. the package authors themselves definitely don't write any makefiles by hand except maybe for trivial packages (and frankly I'm not sure)
- kazinator 6y ago
  Autotools generate a Makefile project, and nothing but a Makefile project. All the buiding in the development cycle is done by typing "make". Autotools projects include a template makefile: Makefile.am. Make is not concealed in any way. Also note that not all Autotools-based projects use Automake. Using only Autoconf, with a hand-maintained Makefile, is a thing. The goal of Autotools is to produce a software distribution that doesn't require the end user to have Autotools. The end user has a shell to run the configure script, and that's it. If that works, they run "make". About the most sophisticated generation the user will see is that some Makefile.in template is passed through sed to substitute @@XYZ@@ variables.
  - anand-bala 6y ago
    This is true for Autotools projects, but isn't true for CMake, Bazel, Meson, and others. Let's take CMake for example, which is IMHO the most popular build tool: most modern CMake projects prefer to use the Ninja build system over Make. And coming back to Autotools, some of the largest Autotools projects (see the GNOME ecosystem) has been moving/moved to Meson, which can also be used to generate Ninja rules instead of Makefiles. CMake Generators: https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html https://cmake.org/cmake/help/latest/manual/cmake-generators.... Meson: https://mesonbuild.com/ https://mesonbuild.com/ Bazel: https://bazel.build/ https://bazel.build/ GNOME and Meson: https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

bluGill 6y ago

I use modern cmake as much as I can, but I often run into things that cmake cannot do without a function. Most of our custom code generation tools for example, cmake doesn't know how to turn them into c++ without a function (which is in turn a wrapper of add custom command /target I've gotten rid of several of our pre modern cmake functions, but more remain.

jcelerier 6y ago

> This is a red flag. If you're hoping to write functions with cmake... You're doing it wrong. Very wrong. You add targets, and you add rules to the target. If you find yourself wanting to do anything other than this then you should take a step back and read a modern cmake tutorial again, because odds are you're doing it wrong. so how do you propose to do code generation, parsing stuff like /etc/lsb_release to work around a bug for people building under ubuntu 16.04, or that kind of thing ?