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

fabricate: The better "make". Finds dependencies automatically for any language.

code.google.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#21

Post by Bluem00 »

garnet7 wrote: post #19
silentbicycle wrote: post #15

Earlier quoted context omitted.

Right. Make already knows how to convert .c to .o, all you need to say is files.c: defs.h buffer.h command.h and there are tools such as makedepend (for C and OCaml, off the top of my head) that generate those listings automatically , so you just add this to the Makefile: include (autogenerated dependency listing file) While the mandatory tab in Make syntax is a genuine wart, make has been around long enough that the…

> make has been around long enough that there are several other tools that know how to work with it. I'd prefer an improved from-scratch 2nd-generation tool instead of using one that simply wraps around a complicated 1st-gen one that I'd rather not touch. Make has more warts than just the tab characters. Lots of obscurely-named variables, for starters.

You might want to check out tup. It uses the dependency tree in a fundamentally different way from make, in order to improve build times. http://gittup.org/tup/

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#22

Post by jimbokun »

st3fan wrote: post #17
thingie wrote: post #16

Do I miss something? That example is like three times longer than an equivalent Makefile would needed to be, and I need to know Python, obviously. For a trivial project, I guess that Make would be easier to use, and for something more complex, I think I would have to do quite a lot of programming, with Fabricate…

What misses in my opinion is 'build by convention'. Most things that you want to build have recipes that are mostly the same. You have some sources that you want to compile and then link against some libraries. Using some platform specific compiler and linker flags. So, instead of writing a program to do the build I would rather see a simple DSL that allows me to specify just the minimal amount of configuration to ge…

What's a-a-p?

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#23

Post by st3fan »

jimbokun wrote: post #22
st3fan wrote: post #17

Earlier quoted context omitted.

What misses in my opinion is 'build by convention'. Most things that you want to build have recipes that are mostly the same. You have some sources that you want to compile and then link against some libraries. Using some platform specific compiler and linker flags. So, instead of writing a program to do the build I would rather see a simple DSL that allows me to specify just the minimal amount of configuration to ge…

What's a-a-p?

See http://a-a-p.sf.net

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#24

Post by kscaldef »

growt wrote: post #4

I haven't tried fabricate yet, but I think the number of build-tools out there is a sure sign that something fundamental is broken.

I wouldn't claim it's the full story, but IMO part of what's fundamentally broken is the phenomenon of single-language programmers. This leads to the belief that your entire tool chain needs to be written in a single language. So now every language has it's own build tool (or 2, or 3), and god help you if you have a multi-language codebase and need to have a unified build system.

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#25

Post by modeless »

growt wrote: post #4

I haven't tried fabricate yet, but I think the number of build-tools out there is a sure sign that something fundamental is broken.

What's broken is the C preprocess/compile/link process. C needs to get a modern module system and ditch the antiquated preprocessor and linker.

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#26

Post by gchpaco »

The central problem with these sorts of "make replacements" is they miss out on the whole thing that makes make useful. I care not a whit about implicit rules, and I would welcome a real language over GNU make's function apparatus (filenames with spaces in them tend to get split in the functions, due to the fundamentally macro style), but without pattern matching rules and a real dependency engine I won't even think once about it. I use both far, far too often, in almost every makefile I've ever written.

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#27

Post by joe_bleau »

silentbicycle wrote: post #13
loup-vaillant wrote: post #10

Earlier quoted context omitted.

I don't get it. Does it intercept file accesses to determine the dependencies? Looks like magic.

Yes, via access times and strace: "When this build stage ran, it checked these files, so remember them as dependencies." Not magic at all, and should automatically work for languages that haven't even been invented yet.

Can it tell (using access times under windows) that the files were modified by that stage of the build command, and not by another unrelated process?

How does it know which drives and directories to scan for recently modified files? Scanning all of them would take a while.

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#28

Post by silentbicycle »

joe_bleau wrote: post #27
silentbicycle wrote: post #13

Earlier quoted context omitted.

Yes, via access times and strace: "When this build stage ran, it checked these files, so remember them as dependencies." Not magic at all, and should automatically work for languages that haven't even been invented yet.

Can it tell (using access times under windows) that the files were modified by that stage of the build command, and not by another unrelated process? How does it know which drives and directories to scan for recently modified files? Scanning all of them would take a while.

It uses strace, a Linux-specific file change notification hook. It's not available on BSD or (IIRC) OS X, though ktrace is, so it could conceivably be ported. (The page says something vague about cygwin having a comparable hook to strace. I haven't developed for cygwin, though.)

It looks like it checks for files modified specifically by its subprocesses.

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#29

Post by silentbicycle »

garnet7 wrote: post #19
silentbicycle wrote: post #15

Earlier quoted context omitted.

Right. Make already knows how to convert .c to .o, all you need to say is files.c: defs.h buffer.h command.h and there are tools such as makedepend (for C and OCaml, off the top of my head) that generate those listings automatically , so you just add this to the Makefile: include (autogenerated dependency listing file) While the mandatory tab in Make syntax is a genuine wart, make has been around long enough that the…

> make has been around long enough that there are several other tools that know how to work with it. I'd prefer an improved from-scratch 2nd-generation tool instead of using one that simply wraps around a complicated 1st-gen one that I'd rather not touch. Make has more warts than just the tab characters. Lots of obscurely-named variables, for starters.

> [complicated tool ...] Lots of obscurely-named variables, for starters.

Are you talking about make or just GNU make? The $http://www.freebsd.org/doc/en/books/pmake/

Re: fabricate: The better "make". Finds dependencies automatically for any language.

#30

Post by sorbits »

I have a machine with two quad-core CPUs, I want to run 8 parallel jobs at a time!

Most of these make replacements start with design decisions (like using Python) that pretty much rule out ever reaching what make does best, and which is essential to get my build times improved by at least a factor of 6.

Using a tool (like CMake) to generate your Makefiles is an excellent solution, heck, even a Python script that generated a Makefile and then ran make would be to prefer over this tool.

Post reply on HN