Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Makefiles – Best Practices

danyspin97.org

Post reply on HN
Print view View original

81–90 of 127 posts

Re: Makefiles – Best Practices

#81

Post by pbalau »

girzel wrote: post #4

I recently decided it was time to get a better understanding of how makefiles work, and after reading a few tutorials, ended up just reading the manual. It's long, but it's very, very well written (a good example of one of the Gnu projects biggest strengths), to the point where just starting at the top and reading gives an almost tutorial-like effect. Just read the manual!

What if I want to use makefiles on a mac? Make of macs is not gnu make.

/edit: bugger, after a make --version on a mac, i've got:

GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc.

Back to the begining, why is this bloody thing not working...

Re: Makefiles – Best Practices

#82

Post by kawera »

pbalau wrote: post #81
girzel wrote: post #4

I recently decided it was time to get a better understanding of how makefiles work, and after reading a few tutorials, ended up just reading the manual. It's long, but it's very, very well written (a good example of one of the Gnu projects biggest strengths), to the point where just starting at the top and reading gives an almost tutorial-like effect. Just read the manual!

What if I want to use makefiles on a mac? Make of macs is not gnu make. /edit: bugger, after a make --version on a mac, i've got: GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. Back to the begining, why is this bloody thing not working...

FYI, homebrew installs version 4.2.1. Invoke it as gmake.

Re: Makefiles – Best Practices

#83

Post by kbumsik »

brookhaven_dude wrote: post #21

What about using Python (with system calls) to build the project? Much more understandable than Makefiles.

I bet Makefile has far more understandable and needs far much less lines than Python for its purpose. Its declarative syntax and "rules" are just suitable for task runners.

Re: Makefiles – Best Practices

#84

Post by Orphis »

RHSeeger wrote: post #20
Orphis wrote: post #15

Makefiles, Best Practices: Don't write Makefiles, use a higher level language to describe your goal and some tool to execute it (either directly or through generating a Ninja file). The Make language is the assembly language of build systems. Do you really enjoy writing assembly all the time?

I have yet to find a build system I prefer over Make. I use Maven at work and use a Makefile to run mvn. It lets me easily run a wide variety of commands locally as part of my build.

Sure, if you're running commands, but you're not building Java directly with it. That seems reasonable.

Re: Makefiles – Best Practices

#85

Post by Orphis »

stonogo wrote: post #75
Orphis wrote: post #19

Earlier quoted context omitted.

What's more simple than "add_executable(foo bar.cpp)"? It's concise, cross-platform and hides all the boilerplate for you. Sure, everything in CMake is not super intuitive, but I've led workshops were people got the hang of it pretty quickly for simple to advanced cases (including multiple targets and some scripting). Keep it simple, most of the time, you don't need the advanced features at all! Can't say the same fo…

> What's more simple than CMake 3.6.0 or higher is required. You are running version 3.5.1

"GNUmake is required, but you are running FreeBSD".

Not saying it's not available there, not all platforms have all software available right away or up to date.

Even then, upgrading CMake is the easiest thing ever: "pip install cmake". Or fetch it from the Github releases page quickly, it's always available as static binaries for all major platforms.

Re: Makefiles – Best Practices

#86

Post by q3k »

self_awareness wrote: post #50
mruts wrote: post #44

Earlier quoted context omitted.

Is this a joke? Why would anyone ever do that? Except if the only language you know (and ever want to know) is python?

Users of SCons ( https://scons.org/ ), and Waf ( https://waf.io/ ) disagree with your point of view.

Incidentally, I have not ever met a single user of either of those that does not hate working with them.

Re: Makefiles – Best Practices

#87

Post by Orphis »

ghthor wrote: post #28
Orphis wrote: post #19

Earlier quoted context omitted.

What's more simple than "add_executable(foo bar.cpp)"? It's concise, cross-platform and hides all the boilerplate for you. Sure, everything in CMake is not super intuitive, but I've led workshops were people got the hang of it pretty quickly for simple to advanced cases (including multiple targets and some scripting). Keep it simple, most of the time, you don't need the advanced features at all! Can't say the same fo…

Its here I look to KISS to guide me. A Makefile is simple and you can expect it to be on most systems, so it's a good place to start stringing things together. It helps you start building a CLI UI with relative ease, once you know you should mark all ephemeral targets as .PHONY. As a project grows and gains users or requires more system support, the growth of Make usage to declare interdependence should always be dis…

It is rather intuitive for someone knowing Make. Even then, which version of Make are you talking about? GNUmake? WHICH VERSION again? 3.82? 4.0? Some features in 4.0 aren't backward compatible of course, so you have to be precise about what you are exactly targeting.

If you are using anything advanced, then it will become unreadable for beginners too. Try to explain delayed and immediate variable interpolation to beginners, that their "VAR = foo" doesn't always work the way they think it does.

On the other hand, yes, the CMake sample above is self explanatory, works on all platforms (more than Make itself), all compilers without having you to write low level compiler invocations, supports IDE for easier debugging (sure, you can also tell your users they have to learn how to use GDB by hand, just... good luck). It will automatically rebuild the right files when their dependencies or command line changes, you don't have to code that by hand for each compiler (and probably have many subtle bugs in your implementation too).

Make has a place for simple things, not for build systems, we have way better ways to do them now, even if you refuse to use them.

Re: Makefiles – Best Practices

#89

Post by kazinator »

chubot wrote: post #25
girzel wrote: post #4

I recently decided it was time to get a better understanding of how makefiles work, and after reading a few tutorials, ended up just reading the manual. It's long, but it's very, very well written (a good example of one of the Gnu projects biggest strengths), to the point where just starting at the top and reading gives an almost tutorial-like effect. Just read the manual!

FWIW I also read the GNU Make manual, and based some code for automatic deps off a profoundly ugly example it had. Then later people on HN showed me a better/simpler way to do it. https://news.ycombinator.com/item?id=15060149 https://www.gnu.org/software/make/manual/html_node/Automatic... After reading the manual and writing 3 substantial Makefiles from scratch, I still think Make is ugly and, by modern standards, no…

> offers you virtually no help in writing correct parallel and incremental builds.

The key problem there that Make has no idea about the semantics of the shell code that appears in the build recipes. It has no idea how two build recipes interact with each other through side effects on objects that are not listed as targets or prerequisites.

I think ClearCase's clearmake (GNU-compatible) actually intercepts the file system calls (because the build happens on a ClearCase mounted VOB). So it is able to infer the real inputs and outputs of a build recipe at run-time. For instance, it would know that "yacc foogrammar.y" produced a "y.tab.h" even if the rules make no mention of this. So in principle it's possible to know that one rule is consuming "y.tab.h" (opens it for reading), that is produced by another rule (that wrote it), without there being any dependency tied to this data flow.

The interception could be done by injecting shared lib wrappers, I suppose. Our friend LD_PRELOAD and all that.

Of course, if we fix the parallel build with proper dependencies, a fixed incremental build also pops out of that.

Post reply on HN