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

81–90 of 143 posts

Re: Build Tools – Make, no more

#81

Post by Too »

Someone wrote: post #74
taeric wrote: post #59

Earlier quoted context omitted.

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…

Invoking the command twice can also screw up things if you run parallel build, which you should always do! Not only to speed things up it's also a good way to verify that your make file actually is correct. If your make file doesn't work in parallel build it is broken, in the same way as C code that breaks at -O2 and above due to reliance on undefined behavior.

The solution to the multiple target problem is using the built in magic .INTERMEDIATE rule which isn't entirely obvious how it works.

Re: Build Tools – Make, no more

#82

Post by CmdrKrool »

nightcracker wrote: post #11

I'm currently working on a build tool that doesn't work using the traditional "makefile" approach. Instead it's designed as a Python library, and you have the full power of Python at your disposal. Sadly it's not ready for prime-time yet (early designing stage), so I won't link my highly unfinished project.

Fabricate might be interesting to you if you haven't seen it already.

https://code.google.com/p/fabricate/

Re: Build Tools – Make, no more

#83

Post by revscat »

ndrake wrote: post #53
revscat wrote: post #34

Earlier quoted context omitted.

Ant is a Turing-complete language in XML. That is horrifying. It is bloated, difficult to read, tends towards duplication. It also doesn't do dependency management all that well, doesn't cache build results (so it does a complete rebuild every time), and is difficult to extend. Not an Ant fan. I have used both Rake and Gradle successfully, and have been much happier with each. Their scripts tend to be (much) more com…

I agree with a lot of your points, but can you explain the part about it doing a complete rebuild every time? It doesn't do that for me (unless I specifically tell it to).

My apologies: I just wrote a basic HelloWorld.java and a build.xml to go with it, and it looks like it doesn't recompile the class unless there is a change to the source .java file. So I was mistaken about that.

Wonder what Gradle's caching, then?

Re: Build Tools – Make, no more

#84

Post by Too »

Might go a bit off topic but i have to bring this up since 9 out of 10 make tutorials on the internet do the same horrific mistake as you just did, 11 out of 10 code bases out in the wild as well.

In your make file example the .o files are just depending on the .cpp files, not the header files they include, the header files those included header files include and the files they include etc etc. This means nothing will be recompiled/relinked if a constant in a header file changes for example! Changed function signatures will give you cryptic linker errors with the standard solution "just try make clean first".

To solve this you can either manually update the make file every time any file changes the files it includes, which almost defeats the purpose of having an automatic build system. Or you can use automatic dependency generation by invoking your compiler with a special flag (-MMD for GCC), and suddenly make isn't as simple anymore as you laid it out to be. In conclusion your build tool must be aware of ALL inclusion rules as your compiler(preprocessor) has, or be given the information somehow. Maybe it's better to just use something designed for your particular toolchain that can come bundled with this knowledge?

Re: Build Tools – Make, no more

#85

Post by andrewflnr »

rkrzr wrote: post #78
chrismonsanto wrote: post #49

Earlier quoted context omitted.

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

My favorite is the "Tup vs Mordor" benchmark.

Re: Build Tools – Make, no more

#86

Post by badman_ting »

vinkelhake wrote: post #50

I find these posts somewhat amusing. We've got people who (rightfully) question the tools they use and look for alternatives. They then discover Make and have some kind of zen Unix moment that they want to share with the world. If what you are doing in your flavor-of-the-month build tool translates to a roughly equivalent number of lines in Make, then yes, you should probably look at using Make. But the thing is, Mak…

I find them irritating for the same reason.

It reminds me of the jQuery cycle: use jQuery for everything -> decide that depending on frameworks is lame -> use "vanilla JS" for everything -> realize this requires polyfills and various other inconvenient, inelegant things -> either go back to using jQuery, or gain a much deeper understanding as to why everyone uses it.

Re: Build Tools – Make, no more

#87

Post by marshray »

nn3 wrote: post #76
marshray wrote: post #70

Earlier quoted context omitted.

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

Because now make can't build a clean source tree.

I believe make parses the entire Makefile before running it.

Re: Build Tools – Make, no more

#88

Post by mzs »

apples2apples wrote: post #43
exogen wrote: post #19

Earlier quoted context omitted.

Could you post an example of what you mean by the single target/file limitation? As stated I can't tell how implicit rules or a rule to build an entire directory wouldn't be a solution, but maybe I'm not understanding the problem.

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…

Or if you don't like taeric's suggestion you can just touch a .ao file after the line that creates the .a and .o files and have your further rule(s) depend on that .ao file. Have .ao depend on your source. If you still want to be able to type stuff like 'make foo.a' instead of 'make foo.ao' and have it work, then you can make a rule where .a depends on .ao and all the rule does is touch the .a file. Create the same rule for the .o too.

Re: Build Tools – Make, no more

#89

Post by X4 »

vinkelhake wrote: post #50

I find these posts somewhat amusing. We've got people who (rightfully) question the tools they use and look for alternatives. They then discover Make and have some kind of zen Unix moment that they want to share with the world. If what you are doing in your flavor-of-the-month build tool translates to a roughly equivalent number of lines in Make, then yes, you should probably look at using Make. But the thing is, Mak…

Amusing indeed. (Functional) Reactive Programming [1] [2] anyone. That's the same thing we've learned during development to be profitable and of real use. And it seems that build systems also converge towards the same lesson learned, but slowly.

––

[1] http://en.wikipedia.org/wiki/Reactive_programming

[2] http://en.wikipedia.org/wiki/Functional_reactive_programming

Re: Build Tools – Make, no more

#90

Post by humanrebar »

Too wrote: post #84

Might go a bit off topic but i have to bring this up since 9 out of 10 make tutorials on the internet do the same horrific mistake as you just did, 11 out of 10 code bases out in the wild as well. In your make file example the .o files are just depending on the .cpp files, not the header files they include, the header files those included header files include and the files they include etc etc. This means nothing wil…

Right. Make is mostly a kludge around the nonexistent module system in C and C++.

It's so bad (specifically due to the way file preprocessing works), that you need to have large parts of a compiler to accurately determine what the dependencies of a source file are.

This is why a decent module system should be the top priority for C++17, though it doesn't look likely so far.

Post reply on HN