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

91–100 of 127 posts

Re: Makefiles – Best Practices

#91

Post by mcguire »

klodolph wrote: post #32
chubot wrote: post #25

Earlier quoted context omitted.

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…

> In my mind, the biggest problem is that it offers you virtually no help in writing correct parallel and incremental builds. That’s interesting, because in my mind, parallel and incremental builds are the main features of Make, the features that it is best at, and all other features are secondary. It sounds like your problem is with the correctness part. Make gives you no tools to enforce that your build rules are a…

I'd just like to point out that Ant, the only alternative to make you list that I've used extensively, is essentially a scripting system.

Re: Makefiles – Best Practices

#92

Post by ghthor »

Orphis wrote: post #87
ghthor wrote: post #28

Earlier quoted context omitted.

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 be…

I'd like to understand where in my comment I stated that I "refused" to use better tools. I even stated that it's important for the team to discuss tooling as a project gains users.

Learning new tools is something I enjoy doing, but as my career continues my focus is changed. I haven't once walked into a project where I've felt the need to re-tool the build system because it wasn't living up to the task. And for your information, my company has a monorepo and we build using pants, which I'm starting to grow quite fond of.

I may have some bias towards learning new tools, likely why I like go so much. All the tools(now that we have modules and MVS), none of the hassle.

Re: Makefiles – Best Practices

#93

Post by kazinator »

jschwartzi wrote: post #64
klodolph wrote: post #32

Earlier quoted context omitted.

> In my mind, the biggest problem is that it offers you virtually no help in writing correct parallel and incremental builds. That’s interesting, because in my mind, parallel and incremental builds are the main features of Make, the features that it is best at, and all other features are secondary. It sounds like your problem is with the correctness part. Make gives you no tools to enforce that your build rules are a…

As I recall, the guy who developed Make wrote it in a weekend.

That may be true, but GNU Make wasn't built in a weekend.

Just like a crappy Lisp interpreter can be built in a weekend, but an ANSI Common Lisp or Racket won't be built in a weekend.

Re: Makefiles – Best Practices

#94

Post by nomel »

umvi wrote: post #9

"Makefile, Best Practices: Use CMake to generate them for you"

You joke, but I've personally never seen a hand made make build systems, in any company I've worked at, that could handle "fuzzing" by deleting or modifying random files in the build system and having the expected output.

They all required a "clean" to get back in order.

For those that maintain handmade make based build system of reasonable complexity, I challenge you to "fuzz" it before each build. It will not be a comfortable experience.

On the other hand, I've seen many generated makefiles that behaved correctly that are totally unreadable.

Re: Makefiles – Best Practices

#95

Post by jjeaff »

I have never worked much with compiled languages but I recently started creating gnu makefiles in all my projects. I read someone's article, maybe from here, that gave me the idea.

I have been putting everything in it. From the terminal commands needed to spin up the cloud infrastructure to all the docker build commands and of course all the build tasks like gulp and composer.

Even my docker compose commands have been replaced with "make up" and "make down". It is really handy and has really streamlined a lot of processes when it comes to local dev environment issues with different developers.

I basically just use it as an easy way to organize shell scripts.

The next step is to convert my ci/cd pipeline to just use specific makefile commands from the same makefile so that everything is more portable and I can easily execute the exact same process locally when desired.

Re: Makefiles – Best Practices

#96

Post by theamk »

Orphis wrote: post #19
jopsen wrote: post #16

Earlier quoted context omitted.

Make is simple.. it gets me started. I can do multiple targets with dependencies and incremental compilation.. Sure, you should be careful of scaling it far. BUT, please enlighten me on a sane high-level build system? cmake, bazel and the like all seems to rely on unintuitive macros. And let's not talk about auto tools :) What other mainstream build system will get you started quickly without unintuitive macros. (I w…

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…

You forgot -Wall. Also, does this enable C++11? And don’t forget to set that NDEBUG macro.

All the things above is still a 2 line Makefile. And it is intuitive, too - you jusy copy your command-line g++ invocation and paste into Makefile.

Re: Makefiles – Best Practices

#97

Post by heyjudy »

If you're using GNU make, as the author appears to be doing, makefiles should be named GNUmakefile instead of Makefile so as to not confuse the user or the tools by conflating GNU make with BSD make or other make dialects.

Re: Makefiles – Best Practices

#98

Post by theamk »

Orphis wrote: post #87
ghthor wrote: post #28

Earlier quoted context omitted.

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 be…

I don’t think I ever saw (GNU)make version problems. Most Makefiles I have seen in the wild were using pretty basic features.

On the other hand, trying to get Kitware’s stuff to compile was a real horror. I ended up adding Docker to the project just to get the right CMake version. And debugging the buildsystem was hell. I hope I never have to touch CMake again in my life.

Re: Makefiles – Best Practices

#99

Post by theamk »

Orphis wrote: post #85
stonogo wrote: post #75

Earlier quoted context omitted.

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

If it was only that simple.. there are packages out there which require specific older version of cmake. So sometimes you have to downgrade, too.

Re: Makefiles – Best Practices

#100

Post by kajm »

nrclark wrote: post #40

GNU Make is an awesome task-runner. I use it all the time, for all sorts of things. It's my shell-script replacement, and I write one-off Makefiles frequently. It's got a nice macro-processor, some helpful string manipulation tools, and expresses task dependencies perfectly. The manual is also very well written. But if you're writing a software package, consider using CMake, Meson, Autotools, or something similar. Un…

> awesome task-runner

I do this too. I have been trying to find examples of people doing something similar on the web but had no luck. I've replaced so many 5-line shell scripts in my user /bin by just having a single makefile in the root of my home directory and having aliases to the various commands defined in the makefile. I even have a rule that shows a rofi menu that allows me to run the rules easily although it's a bit hackish at the moment. Maybe the way to go would be pulling out the parts of Make that are good for a task runner into a separate application and add some nice extensions like .ONESHELL being implicit.

Post reply on HN