Build Tools – Make, no more • Hacker News Board

Re: Build Tools – Make, no more

#121

Post by ArkyBeagle » Tue, Apr 22, 2014, 3:14 AM UTC

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…

This is eminently possible with make-plus-GCC - add the line:

.depend :

        gcc -M *.c > .depend

then at the bottom:

source .depend

Re: Build Tools – Make, no more

#122

Post by feca » Tue, Apr 22, 2014, 3:29 AM UTC

tikhonj wrote: post #94

A build DSL solves the problem of making your build rules and systems first-class citizens . It's not just learning a new syntax—in fact, since you're embedding into a known language, it isn't even that new—it's about getting more control. You can pass rules around, modify them and do whatever arbitrarily complex tasks you need in a natural, straightforward way using your favorite programming language. You don't have…

Can you show an example of what you are describing? It doesn't sound interesting for the tasks I have in mind, so it must be the case that you are dealing with very complex tasks.

Re: Build Tools – Make, no more

#123

Post by cgrubb » Tue, Apr 22, 2014, 3:43 AM UTC

muteh wrote: post #118

cgrubb wrote: post #115

Earlier quoted context omitted.

Your build system has types? Is that so you can catch errors at compile time instead of run time? Who builds the build tool?

I know you're just being glib, but here are some answers: * build doesn't mean compile * you can compile your build process and then use that to actually run your build * the benefits of typed languages go beyond catching errors at compile time

There are tools like ocamlbuild and cabal, which are implemented in Ocaml and Haskell, and used to build Ocaml and Haskell.

But ocamlbuild doesn't have a build file. It just knows how to build Ocaml. And build Ocaml is about all it can do. Cabal is powered by a .cabal file, which is a data structure, and a Setup.hs file, which is run like a shell script via runhaskell.

I think what tikhonj envisions would be a lot of work to achieve. Maybe he already knows that. I suspect that the closest most of us will ever get is putting something like this at the top of a Makefile :)

     .ONESHELL:
     SHELL = /usr/bin/runhaskell

Re: Build Tools – Make, no more

#124

Post by luckydude » Tue, Apr 22, 2014, 4:34 AM UTC

I'm 52 years old. I've had this discussion with dmr, srk, maybe with wnj.

All I know is for years, decades, I carried around the source to some simplistic make. I hate GNU make, I hate some of the unix makes. I loved the simple make.

The beauty of make is it just spelled out what you needed to do. Every darn time make tried to get clever it just made it worse. It seemed like it would be better and then it was not.

Make is the ultimate less is more. Just use it and be happy.

Re: Build Tools – Make, no more

#125

Post by pekk » Tue, Apr 22, 2014, 4:52 AM UTC

ztratar wrote: post #40

sheetjs wrote: post #33

One big advantage of vanilla Make is the community. There are some very nice tools that work well with make (such as https://github.com/mbostock/smash ).

I love documentation that has humor, as long as it doesn't get in the way. What's special about the Make community as opposed to the Grunt or Gulp communities?

For that matter, what's special about the Grunt or Gulp communities?

Re: Build Tools – Make, no more

#126

Post by gradstudent » Tue, Apr 22, 2014, 4:55 AM UTC

tikhonj wrote: post #94

A build DSL solves the problem of making your build rules and systems first-class citizens . It's not just learning a new syntax—in fact, since you're embedding into a known language, it isn't even that new—it's about getting more control. You can pass rules around, modify them and do whatever arbitrarily complex tasks you need in a natural, straightforward way using your favorite programming language. You don't have…

Perhaps I'm just jaded but what you describe sounds a lot more complicated for most people than just writing a Makefile. Perhaps even the vast majority of people. I think you underestimate how far you can go with just a vanilla make build system.

Re: Build Tools – Make, no more

#127

Post by spc476 » Tue, Apr 22, 2014, 5:47 AM UTC

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…

I was able to do that with GNU Make. Granted, the syntax is a bit ... odd, but it was doable.

    ASM = A09/a09

    %.o %.l : %.a
            $(ASM) -o $(*F).o -l $(*F).l $(*F).a

    clean:
            /bin/rm -rf *.o *.l

    foo : disasm.l
    bar : disasm.o
    baz : disasm.l disasm.o

The target baz has both a .l and a .o, both of which are produced in one command. The line that begins with "%.o" starts an implicit rule, which loosely states, in English: "to produce a .o file, or a .l file, run the following ...". $(*F) is a GNUism that maps to the filename of the source (directory part, if any, is stripped). This works. I tested all three targets (foo, bar, baz) with a "make clean" between each one.

(and for the really curious, a09 is a 6809 assembler; disasm.a is a 6809 diassembler, written in 6809; binary is a 2K relocatable library)

Re: Build Tools – Make, no more

#128

Post by ICWiener » Tue, Apr 22, 2014, 6:52 AM UTC

tikhonj wrote: post #94

A build DSL solves the problem of making your build rules and systems first-class citizens . It's not just learning a new syntax—in fact, since you're embedding into a known language, it isn't even that new—it's about getting more control. You can pass rules around, modify them and do whatever arbitrarily complex tasks you need in a natural, straightforward way using your favorite programming language. You don't have…

If you want to use Make, read "Recursive Make Considered Harmful" first (http://aegis.sourceforge.net/auug97.pdf).

Re: Build Tools – Make, no more

#129

Post by ICWiener » Tue, Apr 22, 2014, 6:54 AM UTC

feca wrote: post #122

tikhonj wrote: post #94

A build DSL solves the problem of making your build rules and systems first-class citizens . It's not just learning a new syntax—in fact, since you're embedding into a known language, it isn't even that new—it's about getting more control. You can pass rules around, modify them and do whatever arbitrarily complex tasks you need in a natural, straightforward way using your favorite programming language. You don't have…

Can you show an example of what you are describing? It doesn't sound interesting for the tasks I have in mind, so it must be the case that you are dealing with very complex tasks.

See ASDF, for example (http://common-lisp.net/project/asdf/).

Re: Build Tools – Make, no more

#130

Post by nshepperd » Tue, Apr 22, 2014, 7:01 AM UTC

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…

Huh? Doesn't this work:

    all: copied o a
    source:
    	echo "message" > source
    foo.o foo.a: source
    	(echo -n ".o: "; cat source) > foo.o
    	(echo -n ".a: "; cat source) > foo.a
    o: foo.o
    	cat foo.o > o
    a: foo.a
    	cat foo.a > a
    copied: foo.o foo.a
    	cat foo.o foo.a > copied

The third rule simulates a compiler producing two outputs. Now if foo.o changes, both "copied" and "o" will be updated, and if foo.a changes, both "copied" and "a" will be updated. (And if either foo.o or foo.a are deleted, the compiler will be rerun, as will everything depending on foo.a or foo.o.)

This is gnu make 4.0.