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

Build Tools – Make, no more

hadihariri.com

Post reply on HN
Print view View original

61–70 of 143 posts

Re: Build Tools – Make, no more

#61

Post by hooya »

apples2apples wrote: post #2

Misses the fundamental point that Make is broken for so many things. To begin with you have to have a single target for each file produced. Generating all the targets to get around this is a nightmare that results in unreadable debug messages and horribly unpredictable call paths. nix tried to solve much of this, but I agree it can't compete with the bazillion other options.

> To begin with you have to have a single target for each file produced.

Try this next time (only the pertinent lines are included):

  SOURCES=$(wildcard $(SRCDIR)/*.erl)
  OBJECTS=$(addprefix $(OBJDIR)/, $(notdir $(SOURCES:.erl=.beam)))
  DEPS = $(addprefix $(DEPDIR)/, $(notdir $(SOURCES:.erl=.Pbeam))) $(addprefix $(DEPDIR)/, $(notdir $(TEMPLATES:.dtl=.Pbeam)))

  -include $(DEPS)

  # define a suffix rule for .erl -> .beam
  $(OBJDIR)/%.beam: $(SRCDIR)/%.erl | $(OBJDIR)
	$(ERLC) $(ERLCFLAGS) -o $(OBJDIR) $
I've been using a makefile about 40 lines long and I've never needed to update the makefile as i've added source files. Same makefile (with minor tweaks) works across Erlang, C++, ErlyDTL and other compile-time templates and what have you. Also does automagic dependencies very nicely.

> Generating all the targets to get around this is a nightmare that results in unreadable debug messages and horribly unpredictable call paths.

If you think of Makefiles as a series of call paths, you're going to have a bad time. It's a dependency graph. You define rules for going from one node to the next and let Make figure out how to walk the graph.

Re: Build Tools – Make, no more

#63

Post by evmar »

asb wrote: post #42

I've recently been playing with ninja, which does a good job of not being 'just another make' http://martine.github.io/ninja/ . To quote their website, "Where other build systems are high-level languages Ninja aims to be an assembler.". It's used as a backend for GYP (Google Chromium) and is supported by CMake as well. I've had good success generating the files manually using something like ninja_syntax.py: https://g…

Thanks for the plug! In line with the original post, I'll add that the Ninja manual has a section where we try to convince you to not use Ninja and instead use a more common build system: http://martine.github.io/ninja/manual.html#_using_ninja_for_...

Re: Build Tools – Make, no more

#65

Post by GrinningFool »

gyepi wrote: post #25

1. Since make has builtin suffix rules, the Makefile could be simplified to: CXX=g++ hello: main.o factorial.o hello.o clean: rm -rf *o hello 2. Shameless plug: he didn't mention redo [1], which is simpler than make and more reliable. The comparable redo scripts to the Makefile would be: cat @all.do redo hello EOF cat hello.do o='main.o factorial.o hello.o' redo-ifchange $o g++ $o -o $3 EOF cat default.o.do redo-ifch…

Sorry, but that doesn't appear simpler to me...

Re: Build Tools – Make, no more

#66

Post by ThePhysicist »

SoftwareMaven wrote: post #60
ThePhysicist wrote: post #52

For me, the only justification for using a language-specific build tool (e.g. grunt, rake, paver, ...) is when you actually want to exchange data with a library / program written in that language. On the other hand, you could probably accomplish the same effect using environment variables, with the upside of having a cleaner interface. For those that are curious which build tools exist for Python, here's an (incomple…

You forgot buildout[1], which is probably more than a build system, perhaps putting a toe into the configuration management world. 1. http://www.buildout.org/ Documentation can be challenging to find, and it isn't the most actively developed project in the world, but what it does, it does pretty well (including supporting more than python dependencies).

Thanks for posting the link! I hesitated including configuration management tools since the use case is not the same. There's a lot of interesting stuff going on there though: With Saltstack and Ansible we have two serious "chef" contenders for Python now.

Re: Build Tools – Make, no more

#67

Post by malkia »

pekk wrote: post #38
gyepi wrote: post #25

1. Since make has builtin suffix rules, the Makefile could be simplified to: CXX=g++ hello: main.o factorial.o hello.o clean: rm -rf *o hello 2. Shameless plug: he didn't mention redo [1], which is simpler than make and more reliable. The comparable redo scripts to the Makefile would be: cat @all.do redo hello EOF cat hello.do o='main.o factorial.o hello.o' redo-ifchange $o g++ $o -o $3 EOF cat default.o.do redo-ifch…

redo might be simpler and more reliable, but shell isn't. And redo is encouraging even more work to be done in shell. Additionally, the redo version is more verbose and harder to read. While fancier tasks will make's version look horrible relatively quickly, they won't make redo's version look any better.

To this day I still don't understand redo (I'm just staring at it, and don't get anything) - haven't really read the internals.

With make it was easier for me to grasp the idea (or maybe I was simply 20 years younger then).

Re: Build Tools – Make, no more

#68

Post by malkia »

Make is the "assembly" language for build systems. Qt's qmake/cmake target it, and the output produced is horrible, but then using "make -j8" or qt's own "jom.exe -j8" as replacement for the underperforming nmake.exe and you are all set.

Re: Build Tools – Make, no more

#69

Post by gyepi »

pekk wrote: post #38
gyepi wrote: post #25

1. Since make has builtin suffix rules, the Makefile could be simplified to: CXX=g++ hello: main.o factorial.o hello.o clean: rm -rf *o hello 2. Shameless plug: he didn't mention redo [1], which is simpler than make and more reliable. The comparable redo scripts to the Makefile would be: cat @all.do redo hello EOF cat hello.do o='main.o factorial.o hello.o' redo-ifchange $o g++ $o -o $3 EOF cat default.o.do redo-ifch…

redo might be simpler and more reliable, but shell isn't. And redo is encouraging even more work to be done in shell. Additionally, the redo version is more verbose and harder to read. While fancier tasks will make's version look horrible relatively quickly, they won't make redo's version look any better.

> redo might be simpler and more reliable, but shell isn't.

Not quite sure what you mean here. The scripts don't do anything complicated and redo catches errors that could occur.

As for readability, etc, I suppose it's relative. Simple makefiles do read very nicely. Unfortunately, they aren't always simple and hairy makefiles are just horrible to write, read and maintain. I've had no such problems with do scripts.

Re: Build Tools – Make, no more

#70

Post by marshray »

mturmon wrote: post #57
SchizoDuckie wrote: post #36

Earlier quoted context omitted.

My point was referring to the JS toolchain here mostly. I get that for C, make is the tool for the job.

make is a general-purpose tool for describing dependencies for regenerating files. It would be worth your while to learn make, and try it on your example. Understand that it's a declarative language ("A depends on B"; when "B" changes, here's how to update "A"), and not a scripting tool. This is a good thing. In my experience, make is coupled to Unix. Make is not coupled to C.

On one hand, make typically comes with built-in rules for .c targets.

On the other hand, make can't cleanly handle #include dependency detection. I doubt that there is any major C project where "make extraclean" (or its equivalent) isn't occasionally necessary.

So yeah it's really not very well suited for C.

Post reply on HN