3 ms·

I've been using make files constantly since '76 when I first started programming in (US) 5th grade. It has been one of my career amusements watching the build s

I've been using make files constantly since '76 when I first started programming in (US) 5th grade. It has been one of my career amusements watching the build systems come and go. I gave up talking about Make years ago. There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. I use one of the earliest Make versions that barely does anything beyond recognize rules, rule actions, and simplistic macros. I've seen this version of Make used to build a feature animated film. Witnessing the versatility of that feature film's multitude of software and renders and composites all built through Make taught me Make is the only tool needed for any building of anything. I remember when MS introduced a Make with extensions, and many developers ran over and fucked up their build environments, starting them on the path to the complex manual required build mess most people have today. I write my Make films by hand, still. It is that easy. And you really should have a build environment that is that easy. When you need it easy, as in some major deadline and crap is broken, you will thank yourself.

kruhft 9y ago
Which version of make do you use? The one packaged in the 'heirloom' setup, or something different that's still available?
johnhenry 9y ago
You make a few statements regarding films: First, "I've seen this version of Make used to build a feature animated film" and later you state "I write my Make films by hand". I suspect the second statement might be a type-o -- accidentally using "films" in place of "files" -- but in the case that it's not, I wonder if you could detail the practice of "Make films" -- seems like it might be interesting.
- bsenftner 9y ago
  I meant "make feature animated films". During the late 80's, before more 'sophisticated'; build tools polluted developer's young brains, early visual effects were "nothing more" than complex Makefiles triggering renders and composites. All one needed was a facility that looked at the date stamp of two files, and if one was older that meant these series of command lines is executed. Beyond very basic #define style macro substitution, that was all that was used to create many feature film effects, as well as nearly ever single early 3D animated renderer produced animation before 1992.
sigil 9y ago
> I've seen this version of Make used to build a feature animated film. Witnessing the versatility of that feature film's multitude of software and renders and composites all built through Make taught me Make is the only tool needed for any building of anything. Awesome, tell us more! Which film was this? Or if you can't say, what year was it made? I have to imagine The Makefile Architecture is still pretty popular in VFX pipelines. I run a SaaS that's made end credits for hundreds of feature films (including "Moonlight"). Our render pipeline uses The Makefile Architecture.
- bsenftner 9y ago
  The first time I saw Make used in feature production was reviewing the "Last StarFigher" (1984) digital archives. This was after years of working in scientific visualization, and skirting VFX. Previously, while working in visualizations, Make was king for creating NASA, research publication and geologic animations. Much later, I saw Make in heavy use when entering the visual effects industry, but this was after another 15 years in the console video game industry. It was an incredibly welcome realization, after the, frankly, incredible cluster fuck and demoralizing experience of 15 years creating video games, to learn that the rational UNIX-paradigm (small simple tools) community I'd grown up in was alive in the VFX industry. Returning to the 'old school developers' I'd left in the left 80's was so reassuring to learn the tech world had not completely been brainwashed.
humanrebar 9y ago
> There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. They get the things done they've been doing all along. But build metadata is very important and very hard to extract from Makefiles, especially as builds increase in complexity. You need things like search paths accessible to get IDEs, static analyzers, software packaging systems, and other third party tools working with your code base. So make works great if the only things you're interested in doing are the top-level make commands you define, but it doesn't do you any favors when it comes to other things.
- taeric 9y ago
  Search paths accessible to other tools would have been just as well served standardizing search paths. Or, sadly, following standardized search paths. Instead, the new tools came and each one would buck any preceding trend and introduce a new way of doing things. Often poorly. All the while introducing yet another new way of executing the actual build. Let me preempt with saying that Make is not perfect. I genuinely feel that many things could have been improved on. However, I also question how many lessons learned in Make were carried forward, versus how many mistakes were just reintroduced and hit again and again.
- Walf 9y ago
  I don't understand your reasoning here. Make can call any program, and contain as many build targets as you would ever need. If some task can't be accomplished in Make itself or existing CLI programs, you write something that does that one task well, then ensure Make runs it whenever needed, even if that's every build.
  - humanrebar 9y ago
    You could write make rules to do about anything, sure. But you don't want to have to rewrite those rules for every project. You want make modules that you can reuse from project to project. Those are notoriously hard to get right. And when they are done correctly, they are hard to share across organizations, or even within large organizations. In particular, I write a lot of C++. I want targets for gcov, g++, gtest, dpkg, rpm, clang-format, clang-tidy, cppcheck, clang, CLion, Eclipse, ctags, and include-what-you-use. Am I supposed to maintain each of those targets on each of my repos? It's simpler to have a standard place with all the needed source files, binaries, search paths, definitions, etc., and just wire that data up to each extra target.

kruhft 9y ago

Which version of make do you use? The one packaged in the 'heirloom' setup, or something different that's still available?

johnhenry 9y ago

You make a few statements regarding films: First, "I've seen this version of Make used to build a feature animated film" and later you state "I write my Make films by hand". I suspect the second statement might be a type-o -- accidentally using "films" in place of "files" -- but in the case that it's not, I wonder if you could detail the practice of "Make films" -- seems like it might be interesting.

bsenftner 9y ago
I meant "make feature animated films". During the late 80's, before more 'sophisticated'; build tools polluted developer's young brains, early visual effects were "nothing more" than complex Makefiles triggering renders and composites. All one needed was a facility that looked at the date stamp of two files, and if one was older that meant these series of command lines is executed. Beyond very basic #define style macro substitution, that was all that was used to create many feature film effects, as well as nearly ever single early 3D animated renderer produced animation before 1992.

sigil 9y ago

> I've seen this version of Make used to build a feature animated film. Witnessing the versatility of that feature film's multitude of software and renders and composites all built through Make taught me Make is the only tool needed for any building of anything. Awesome, tell us more! Which film was this? Or if you can't say, what year was it made? I have to imagine The Makefile Architecture is still pretty popular in VFX pipelines. I run a SaaS that's made end credits for hundreds of feature films (including "Moonlight"). Our render pipeline uses The Makefile Architecture.

bsenftner 9y ago
The first time I saw Make used in feature production was reviewing the "Last StarFigher" (1984) digital archives. This was after years of working in scientific visualization, and skirting VFX. Previously, while working in visualizations, Make was king for creating NASA, research publication and geologic animations. Much later, I saw Make in heavy use when entering the visual effects industry, but this was after another 15 years in the console video game industry. It was an incredibly welcome realization, after the, frankly, incredible cluster fuck and demoralizing experience of 15 years creating video games, to learn that the rational UNIX-paradigm (small simple tools) community I'd grown up in was alive in the VFX industry. Returning to the 'old school developers' I'd left in the left 80's was so reassuring to learn the tech world had not completely been brainwashed.

humanrebar 9y ago

> There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. They get the things done they've been doing all along. But build metadata is very important and very hard to extract from Makefiles, especially as builds increase in complexity. You need things like search paths accessible to get IDEs, static analyzers, software packaging systems, and other third party tools working with your code base. So make works great if the only things you're interested in doing are the top-level make commands you define, but it doesn't do you any favors when it comes to other things.

taeric 9y ago
Search paths accessible to other tools would have been just as well served standardizing search paths. Or, sadly, following standardized search paths. Instead, the new tools came and each one would buck any preceding trend and introduce a new way of doing things. Often poorly. All the while introducing yet another new way of executing the actual build. Let me preempt with saying that Make is not perfect. I genuinely feel that many things could have been improved on. However, I also question how many lessons learned in Make were carried forward, versus how many mistakes were just reintroduced and hit again and again.
Walf 9y ago
I don't understand your reasoning here. Make can call any program, and contain as many build targets as you would ever need. If some task can't be accomplished in Make itself or existing CLI programs, you write something that does that one task well, then ensure Make runs it whenever needed, even if that's every build.
- humanrebar 9y ago
  You could write make rules to do about anything, sure. But you don't want to have to rewrite those rules for every project. You want make modules that you can reuse from project to project. Those are notoriously hard to get right. And when they are done correctly, they are hard to share across organizations, or even within large organizations. In particular, I write a lot of C++. I want targets for gcov, g++, gtest, dpkg, rpm, clang-format, clang-tidy, cppcheck, clang, CLion, Eclipse, ctags, and include-what-you-use. Am I supposed to maintain each of those targets on each of my repos? It's simpler to have a standard place with all the needed source files, binaries, search paths, definitions, etc., and just wire that data up to each extra target.