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

51–60 of 143 posts

Re: Build Tools – Make, no more

#51

Post by foxhill »

cscheid wrote: post #17
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.

I suspect your downvotes are coming because you haven't mentioned http://www.scons.org/ . Letting you know in case you're not aware of it. (I would have emailed you out-of-band, but there's no contact info in your profile. Sorry for the noise, everyone else)

i suspect that the downvotes from people are because python is far too powerful as a build scripting language.

Re: Build Tools – Make, no more

#52

Post by ThePhysicist »

For me, the only justification for using a language-specific build tool (e.g. grunt, rake, paver, ...) is when you actually want to exchange data with a library / program written in that language. On the other hand, you could probably accomplish the same effect using environment variables, with the upside of having a cleaner interface.

For those that are curious which build tools exist for Python, here's an (incomplete) list:

* pyinvoke (https://github.com/pyinvoke) - claims to be the successor of fabric, pretty solid and well-maintained

* fabric (http://www.fabfile.org/) - not actually a build tool but often used as one

* paver (http://paver.github.io/paver/) - no longer actively maintained

* doit (http://pydoit.org/) - one of the few tools that actually support monitoring file states (like the original make)

* disttools (https://docs.python.org/2/distutils/) - not actually a "universal" build tool but intended to distribute Python packages

Re: Build Tools – Make, no more

#53

Post by ndrake »

revscat wrote: post #34
eponeponepon wrote: post #4

I'm unreasonably fond of Ant - there's plenty of scope for pointless clever-dickery, and there are days where that's all that keeps me going! Nice to see it mentioned in a context other than "oh god what a mess"... even though, in fairness, many aspects of it are a complete dog's dinner.

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

Re: Build Tools – Make, no more

#54

Post by hhariri »

geuis wrote: post #3

Dunno if the owner of the site will read this, but here's a tip. Don't show a full screen overlay telling me how my visit would be better with cookies enabled. 1) I have cookies enabled. 2) The Eurpoean law is daft, but since you feel you must comply do it in a more user friendly way.

I know. I don't agree with it much either and I found this least intrusive (wasn't aware of issue on mobile). If I can find a better solution, will change.

Thanks.

Re: Build Tools – Make, no more

#55

Post by Touche »

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…

Seconded on tup's greatness. Go through the example to see what all it's doing:

http://gittup.org/tup/ex_a_first_tupfile.html

Re: Build Tools – Make, no more

#57

Post by mturmon »

SchizoDuckie wrote: post #36
MarkPNeyer wrote: post #31

Earlier quoted context omitted.

> this stuff took 2 years to evolve and a lot of people went through hours of frustration GMake was first released in 1977: http://en.wikipedia.org/wiki/Make_(software) They've worked on this thing for decades There are 42,000 issues filed for make. if you could resolve each of these issues in 10 minutes, you'd spend 291 days of frustration. http://savannah.gnu.org/bugs/?group=make kids these days.

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.

Re: Build Tools – Make, no more

#58

Post by emelski »

MarkPNeyer wrote: post #31
SchizoDuckie wrote: post #12

So he's saying use 'make' instead of gulp/grunt and then he submits an example where it's as easy as piping through GCC. He's making the wrong assumption that you don't need to setup a build environment when building with make, but to have gcc you will still also need to install g++ and build-tools. Also, he refers to building on Windows using yet another specialist tool, but have you recently tried building anything…

> this stuff took 2 years to evolve and a lot of people went through hours of frustration GMake was first released in 1977: http://en.wikipedia.org/wiki/Make_(software) They've worked on this thing for decades There are 42,000 issues filed for make. if you could resolve each of these issues in 10 minutes, you'd spend 291 days of frustration. http://savannah.gnu.org/bugs/?group=make kids these days.

_make_ was first released in 1977, but that was the PWB/UNIX version. The GNU variant of make didn't come along until sometime in the 1980's. It's hard to pin down the exact date of the first release because the developers didn't keep good records prior to the switch from RCS to CVS. However, the earliest ChangeLog entry now is dated July 15, 1988, and 1985 is the earliest date mentioned in any copyright statement in any of the GNU make source files.

Re: Build Tools – Make, no more

#59

Post by taeric »

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 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 that way right now. I thought the norm was to at least touch all output files.

Further, if that is happening, seems you are safest having two rules, anyway.

Re: Build Tools – Make, no more

#60

Post by SoftwareMaven »

ThePhysicist wrote: post #52

For me, the only justification for using a language-specific build tool (e.g. grunt, rake, paver, ...) is when you actually want to exchange data with a library / program written in that language. On the other hand, you could probably accomplish the same effect using environment variables, with the upside of having a cleaner interface. For those that are curious which build tools exist for Python, here's an (incomple…

You forgot buildout[1], which is probably more than a build system, perhaps putting a toe into the configuration management world.

1. http://www.buildout.org/

Documentation can be challenging to find, and it isn't the most actively developed project in the world, but what it does, it does pretty well (including supporting more than python dependencies).

Post reply on HN