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

11–20 of 44 posts

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

#11

Post by silentbicycle »

It looks like they hardcoded gcc as the compiler in the example. What about trying to port a program to a platform without it (or that calls it differently), that needs extra compilation flags, etc.?

A lot of the seemingly esoteric stuff in Makefiles is there to make porting feasible (and the rest is autogenerated by autoconf, automake, etc.). Not just which files an operation depends on, but e.g. the options used for building shared libraries correctly on this platform, paths for libraries, etc. While the build system will remember what it found as dependencies, it still needs to know what to find the first time. (It will note header files as dependencies, though.)

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

#12

Post by pmorici »

looks a lot like SCube only way more verbose for the simple case. http://code.google.com/p/scube/wiki/Example1

The problem with this and other Python build tools is They are a huge pain to use on older systems that either don't have a recent enough version of Python installed or don't have Python installed at all. It's just not as portable as Make is in that respect.

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

#13

Post by silentbicycle »

loup-vaillant wrote: post #10
benhoyt wrote: post #3

We've been using memoize to build stuff for a while now, but we needed something that worked under Windows too. So here's our "fabricate" build tool. It's BSD licensed -- enjoy!

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.

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

#14

Post by tsally »

You don't need to enter in dependencies with 'make' either (suffix rules or makedepend). Don't get me wrong, fabricate looks great, but let's not misrepresent the power of make in the right hands. From the docs:

   files.o : files.c defs.h buffer.h command.h
         cc -c files.c
I don't know a programmer beyond the introductory level that still writes this in their make file. :-p

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

#15

Post by silentbicycle »

tsally wrote: post #14

You don't need to enter in dependencies with 'make' either (suffix rules or makedepend). Don't get me wrong, fabricate looks great, but let's not misrepresent the power of make in the right hands. From the docs: files.o : files.c defs.h buffer.h command.h cc -c files.c I don't know a programmer beyond the introductory level that still writes this in their make file. :-p

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 there are several other tools that know how to work with it.

(Now, having the scan for access time changes added as a warning to Make might not be a bad idea. "WARNING: You forgot this dependency")

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

#16

Post by thingie »

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…

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

#17

Post by st3fan »

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 get things going.

For example building the example on the fabricate wiki page, should not be more complicated than:

  :program programname : program.c utils.c
(This is actually an a-a-p recipe that will do the same. Throw this in a main.aap file and you get everything that fabricate does, build, dependency checks, clean, etc.)

I don't mind to script the build when things get more complex. But only then and only when there really is no simple built-in alternative.

Fabricate seems to be more like ant in the Java world. Where you specify in detail what your build should do. Most people have agreed by now that it is a waste of time and instead use Maven, which completely works on simple conventions and standard rules.

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

#18

Post by kragen »

benhoyt wrote: post #3

We've been using memoize to build stuff for a while now, but we needed something that worked under Windows too. So here's our "fabricate" build tool. It's BSD licensed -- enjoy!

Does it scan your entire filesystem for atimes so as not to miss the .h files over in /usr/include, and if not, how does it know which directories need scanning?

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

#19

Post by garnet7 »

silentbicycle wrote: post #15
tsally wrote: post #14

You don't need to enter in dependencies with 'make' either (suffix rules or makedepend). Don't get me wrong, fabricate looks great, but let's not misrepresent the power of make in the right hands. From the docs: files.o : files.c defs.h buffer.h command.h cc -c files.c I don't know a programmer beyond the introductory level that still writes this in their make file. :-p

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.

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

#20

Post by moe »

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…

I don't get it either. This is the second build system done in python I come across (the other would be SCons) and both are utter failures.

Make has its quirks, lots of them. But it wouldn't be the most popular build-tool in the world if it was all wrong. So, my hint to the next guy trying to reinvent it: Take a very close look at Make first and then improve on it. Don't start in a clean-room because then you're doomed to repeat build-system history, including all the past mistakes (edit: unless you're Linus Torvalds, perhaps).

Also the build-system is an area where a sane DSL makes perfect sense. Don't make me write procedural code by default. I don't want to see lines like the following in my build-scripts:

    objects = ' '.join(s + '.o' for s in sources)
Post reply on HN