4 ms·

>I personally hate Make, it's burned me too many times. I’d be interested in hearing about the problems Make has caused you— Whenever I’ve needed to write or e

by kd5bjo 7y ago

>I personally hate Make, it's burned me too many times. I’d be interested in hearing about the problems Make has caused you— Whenever I’ve needed to write or edit a makefile, it’s been a pain looking up the relevant details in the manual, but nothing as severe as what you seem to be implying. Have I just been lucky, working with less complicated projects, or something else?

leggomylibro 7y ago
Sometimes you can make mistakes which delete files, but you should keep development files backed up in some capacity. Still, spot the bug here: AS_SRC = main.S util.s OBJ = $(AS_SRC: .S=.o) [...] clean: rm -f $(OBJ)
- rootlocus 7y ago
  Whatever the bug, git reset is the solution.
- kd5bjo 7y ago
  The source files with a lower-case extension aren’t getting their file names translated and are passed straight through into OBJ unchanged. Granted, knowing that there’s an error here helped greatly in spotting it; there’s a good chance I would have run the incorrect makefile at least once before investigating.
umvi 7y ago
> I’d be interested in hearing about the problems Make has caused you The main problem that kept burning me was that I'd have a "dirty" build when I thought I had a clean one or an incorrect one when I thought I had a correct one. It was super hard to get the dependency graph correct because developers were creating files left and right but would only update the Makefile just enough to get it building (and forget to add new header files to the list of headers, etc) so I had little confidence in incremental builds and was always building from the ground up. CMake's generated build systems always have correct dependency graphs (i.e. it will only rebuild the bare minimum when you touch a given file) and I've always had complete confidence that my build is clean (since I just created a fresh directory) and that my incremental builds are correct.
- kd5bjo 7y ago
  That makes a lot of sense. Setting up automatic dependency detection is what finally made Make click for me, and it’s not the most straightforward process to get right. How does CMake detect the files that a given product depends on; does it have language-specific dependency detection or something else?
  - umvi 7y ago
    > How does CMake detect the files that a given product depends on; does it have language-specific dependency detection or something else? Well actually, CMake is a build system generator - and the default build system it generates is Unix Makefiles. So I assume CMake generates Makefiles with the appropriate automatic dependency detection baked in, I'm not sure. The important part was that it eliminated human error on our team and we haven't had dependency graph problems since.
    - deng 7y ago
      CMake has its own dependency scanner for C/C++. Look for a file 'depend.make' and you'll see the header dependencies that CMake has detected, minus the headers that CMake thinks are system headers.
- deng 7y ago
  > and forget to add new header files to the list of headers This is why gcc/clang have the option to generate Makefiles for the header dependencies for you. Maintaining these yourself is a hopeless effort.
msluyter 7y ago
Not the original parent, but the problem I've noticed most recently with make is when people use it to orchestrate building/running docker containers. I've seen several cases where containers will be pulled/rebuilt on every invocation (even if they don't need to be) because there's no file based dependency to indicate they're actually up to date. While docker's layer caching helps with this, it still can add a fair bit of time in some cases. I've worked around that in the past by creating empty "target files" that are created when a given target is built and which dependencies rely on, but it's not a perfect solution. I've looked around for a make alternative, but although I like rake, I don't really use Ruby these days, and so dealing with RVM/rbenv and whatnot is sort of a pain and not worth the effort over make.

by kd5bjo 7y ago

leggomylibro 7y ago

Sometimes you can make mistakes which delete files, but you should keep development files backed up in some capacity. Still, spot the bug here: AS_SRC = main.S util.s OBJ = $(AS_SRC: .S=.o) [...] clean: rm -f $(OBJ)

rootlocus 7y ago
Whatever the bug, git reset is the solution.
kd5bjo 7y ago
The source files with a lower-case extension aren’t getting their file names translated and are passed straight through into OBJ unchanged. Granted, knowing that there’s an error here helped greatly in spotting it; there’s a good chance I would have run the incorrect makefile at least once before investigating.

umvi 7y ago

> I’d be interested in hearing about the problems Make has caused you The main problem that kept burning me was that I'd have a "dirty" build when I thought I had a clean one or an incorrect one when I thought I had a correct one. It was super hard to get the dependency graph correct because developers were creating files left and right but would only update the Makefile just enough to get it building (and forget to add new header files to the list of headers, etc) so I had little confidence in incremental builds and was always building from the ground up. CMake's generated build systems always have correct dependency graphs (i.e. it will only rebuild the bare minimum when you touch a given file) and I've always had complete confidence that my build is clean (since I just created a fresh directory) and that my incremental builds are correct.

kd5bjo 7y ago
That makes a lot of sense. Setting up automatic dependency detection is what finally made Make click for me, and it’s not the most straightforward process to get right. How does CMake detect the files that a given product depends on; does it have language-specific dependency detection or something else?
- umvi 7y ago
  > How does CMake detect the files that a given product depends on; does it have language-specific dependency detection or something else? Well actually, CMake is a build system generator - and the default build system it generates is Unix Makefiles. So I assume CMake generates Makefiles with the appropriate automatic dependency detection baked in, I'm not sure. The important part was that it eliminated human error on our team and we haven't had dependency graph problems since.
  - deng 7y ago
    CMake has its own dependency scanner for C/C++. Look for a file 'depend.make' and you'll see the header dependencies that CMake has detected, minus the headers that CMake thinks are system headers.
deng 7y ago
> and forget to add new header files to the list of headers This is why gcc/clang have the option to generate Makefiles for the header dependencies for you. Maintaining these yourself is a hopeless effort.

msluyter 7y ago

Not the original parent, but the problem I've noticed most recently with make is when people use it to orchestrate building/running docker containers. I've seen several cases where containers will be pulled/rebuilt on every invocation (even if they don't need to be) because there's no file based dependency to indicate they're actually up to date. While docker's layer caching helps with this, it still can add a fair bit of time in some cases. I've worked around that in the past by creating empty "target files" that are created when a given target is built and which dependencies rely on, but it's not a perfect solution. I've looked around for a make alternative, but although I like rake, I don't really use Ruby these days, and so dealing with RVM/rbenv and whatnot is sort of a pain and not worth the effort over make.