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

71–80 of 143 posts

Re: Build Tools – Make, no more

#71

Post by pmahoney »

malkia wrote: post #67
pekk wrote: post #38

Earlier quoted context omitted.

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

I think the big difference between redo and make is that make requires knowledge of dependencies up front, and this is sometimes tricky to get right.

"as you can see in default.o.do, you can declare a dependency after building the program. In C, you get your best dependency information by trying to actually build, since that's how you find out which headers you need. redo is based on the following simple insight: you don't actually care what the dependencies are before you build the target; if the target doesn't exist, you obviously need to build it. Then, the build script itself can provide the dependency information however it wants; unlike in make, you don't need a special dependency syntax at all. You can even declare some of your dependencies after building, which makes C-style autodependencies much simpler."

https://github.com/apenwarr/redo

Re: Build Tools – Make, no more

#72

Post by gyepi »

malkia wrote: post #67
pekk wrote: post #38

Earlier quoted context omitted.

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

It's actually quite simple. You write a short shell script to produce the output you need and redo handles the dependencies.

For example, the shell script named "banana.x.do" is expected to produce the content for the file named "banana.x".

When you say

    # redo banana.x
redo invokes banana.x.do with the command:

    sh -x banana.x.do banana.x banana XXX > ZZZ
so banana.x.do is invoked with three arguments and its output is redirected to a file.

   $1 denotes the target file
   $2 denotes the target file without its extension
   $3 is a temp file: XXX, in this case.
banana.x.do is expected to either produce output in $3 or write to stdout, but not both. If there are no failures redo will chose the correct one, rename the output to banana.x and update the dependency database.

If banana.x depends on grape.y, you add the line

    redo-ifchange grape.y
to the banana.x.do, creating a dependency. redo will rebuild grape.y (recursively) when necessary.

The only other commands I haven't mentioned are init and redo-ifcreate, which are obvious and rarely used, respectively.

That's it.

Re: Build Tools – Make, no more

#73

Post by msluyter »

Nothing against make, but I've found that it feels really nice when the majority of your toolset uses the same language. This is what I liked about Rails. Rails is ruby. Bundler is ruby. Rake is ruby. It's all ruby, which allows for a certain synergy, streamlined feel, and less cognitive overhead. I don't blame the js folks for attempting something similar.

Re: Build Tools – Make, no more

#74

Post by Someone »

taeric wrote: post #59
apples2apples wrote: post #43

Earlier quoted context omitted.

Sure, consider a compiler that produces an (foo.o) object file and an annotation (foo.a). Now if a target requires both foo.o and foo.a you have to create two targets on them (even though its really one command). You can do implicit rules which requires a very verbose makefile, which is what automake and other make generation tools do. God help you figure out what went wrong. If you make people go to a directory appr…

I don't understand. If both the .o and the .a are created from another file, wouldn't it be safe to just rely on either one of them? (Obviously, you will need to be consistent in choice.) That is, if every time a .o is created, so is the .a, then where is the difficulty? Just rely on one (the .o). I could conceive of a scenario where the .a updated but the .o didn't, but I don't know of any tools that really work tha…

Say you have a long build process and do a quick semi-clean by hand to speed up the next buld (not the best idea, but not inconceivable), deleting the .a files, but fogetting to delete the matching .o files. Then, your next build will produce some novel (to you) error messages that may take long to clean up. Worse, the command building on the .o and the .a might just say "OK, I'm given a .o without a .a; fine, then I'll do a slightly different thing"

Also, having two rules means duplicating a command:

    foo: foo.a
        baz $(BAZ_OPTIONS) foo

    foo: foo.o
        baz $(BAZ_OPTIONS) foo
That's bad from a maintenance perspective.

Re: Build Tools – Make, no more

#75

Post by Rusky »

chrismonsanto wrote: post #49
rafekett wrote: post #47

the last 10 years in build tools has felt like 1 step forward, two steps back. i like being able to write tasks in any language other than Makefile. however, it seems like many of the new popular options (cake, grunt, etc.) don't do what, to me, is Make's real purpose: resolve dependencies and only rebuild what's necessary. new task runners have either eliminated or pigeonholed the (typically one-to-one in makeland)…

> however, it seems like many of the new popular options (cake, grunt, etc.) don't do what, to me, is Make's real purpose: resolve dependencies and only rebuild what's necessary. You might like tup[1]. Its killer feature is that it automatically determines file-based dependencies by tracking reads and writes (using a FUSE filesystem). It has an extreme emphasis on correct, repeatable builds, and is very fast. Other s…

+1 for the link. I hadn't seen tup before, and I really like how it feels like make in its simplicity, but is more explicit about the graph inputs and outputs, cares more about the output (e.g. deleting old files), and watches the file system for changes.

Re: Build Tools – Make, no more

#76

Post by nn3 »

marshray wrote: post #70
mturmon wrote: post #57

Earlier quoted context omitted.

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.

What is wrong wrong with just using the following.

Given it would be nice if make had a builtin macro to do this, but it is not too bad to type out.

depend: .depend

.depend: ${SRC} ${CC} -MM -I. ${SRC} > .depend.X && mv .depend.X .depend

include .depend

Makefile: .depend

Re: Build Tools – Make, no more

#77

Post by Silhouette »

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.

In my experience, make is coupled to Unix. Make is not coupled to C.

However, implementations typically include magic that is heavily biased toward building C and C++ code. As someone who works on a lot of projects, some using those languages and some not, I tend to think it's rather too magical at times. Personally, I'd prefer to have that kind of magic explicitly stated in some standard file that comes with the tool, so that file can be included with a one-liner for those projects that want it but there is nothing implicit going on by default.

Re: Build Tools – Make, no more

#78

Post by rkrzr »

chrismonsanto wrote: post #49
rafekett wrote: post #47

the last 10 years in build tools has felt like 1 step forward, two steps back. i like being able to write tasks in any language other than Makefile. however, it seems like many of the new popular options (cake, grunt, etc.) don't do what, to me, is Make's real purpose: resolve dependencies and only rebuild what's necessary. new task runners have either eliminated or pigeonholed the (typically one-to-one in makeland)…

> however, it seems like many of the new popular options (cake, grunt, etc.) don't do what, to me, is Make's real purpose: resolve dependencies and only rebuild what's necessary. You might like tup[1]. Its killer feature is that it automatically determines file-based dependencies by tracking reads and writes (using a FUSE filesystem). It has an extreme emphasis on correct, repeatable builds, and is very fast. Other s…

I was already sold on tup after reading the first paragraph comparing it to make[1]:

"This page compares make to tup. This page is a little biased because tup is so fast. How fast? This one time a beam of light was flying through the vacuum of space at the speed of light and then tup went by and was like "Yo beam of light, you need a lift?" cuz tup was going so fast it thought the beam of light had a flat tire and was stuck. True story. Anyway, feel free to run your own comparisons if you don't believe me and my (true) story."

[1]: http://gittup.org/tup/make_vs_tup.html

Re: Build Tools – Make, no more

#79

Post by Karellen »

marshray wrote: post #70
mturmon wrote: post #57

Earlier quoted context omitted.

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.

Well, #include resolution would require that make be able to parse C, which would add a heck of a lot of complexity, and be unscalable. For instance, you'd need to modify make to parse CSS to teach it about @import, or to parse javascript to teach it about require() (but only if you're using RequireJS)

Or, you could use the C preprocessor option "-M" and its variants[0] to get it to generate make rules with C #include resolution for you.

See also Recursive Make Considered Harmful[1] for a good description on how to set up this in combination with GNU make's "include" facility to autogenerate your per-source #include resolution fragments.

[0] http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html

[1] http://aegis.sourceforge.net/auug97.pdf

Re: Build Tools – Make, no more

#80

Post by gcv »

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 is pretty cool, but I ran into trouble with apenwarr's implementation (https://github.com/apenwarr/redo, see https://groups.google.com/d/msg/redo-list/GL5z8eEqT90/tk_vLZ...) with OS X Mavericks. I have no experience with the alternative implementation at https://github.com/gyepisam/redux, since it came out after I reimplemented the build system in question with CMake.

In general, I found CMake quite useable for my needs, and quite clean. It also required less build system code than redo. CMake fits quite nicely into a (C or C++) project which consists of many binaries and libraries which can depend on each other.

Post reply on HN