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

101–110 of 143 posts

Re: Build Tools – Make, no more

#101

Post by Cyranix »

msluyter wrote: post #73

Nothing against make, but I've found that it feels really nice when the majority of your toolset uses the same language. This is what I liked about Rails. Rails is ruby. Bundler is ruby. Rake is ruby. It's all ruby, which allows for a certain synergy, streamlined feel, and less cognitive overhead. I don't blame the js folks for attempting something similar.

Agreed. Mixing languages is fine when necessary, but a single language is usually preferable to me. My dev team has been using Grunt in projects thus far and have been pleased with Gulp in small experiments.

Re: Build Tools – Make, no more

#102

Post by marshray »

nn3 wrote: post #97
marshray wrote: post #87

Earlier quoted context omitted.

Because now make can't build a clean source tree. I believe make parses the entire Makefile before running it.

GNU make restarts when a Makefile: dependency changes. So it works perfectly fine. Try it ...

What happens if you list depend as a dependency of the first target?

Re: Build Tools – Make, no more

#103

Post by endgame »

erikb wrote: post #93
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…

Is that solved with autotools? I'm not an expert, but I wonder why people talk about pure Make where a lot of bigger projects actually use autotools.

Yes, it is. automake will generate makefiles that track dependencies as a side-effect of compilation ( http://www.gnu.org/software/automake/manual/automake.html#De... ). What this means is that whenever a source file is compiled it will update the dependencies for the .o file. It has to be done then because different platforms could have different header dependencies (if you're having fun with #define).

Re: Build Tools – Make, no more

#104

Post by mikewhy »

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…

    $ cat Makefile
    production:
      brunch build --production

    test:
      brunch build
      karma start

Re: Build Tools – Make, no more

#105

Post by malkia »

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…

I think MSBuild does something like this - there is a filetracker that tracks what files were read/written while running a tool, and writes that information in a file. I think you can even install your own file-notification-changes .dll to track changes your way (maybe file system that is not supported, or something else).

Similar to what lsof, procmon (windows) do.

Re: Build Tools – Make, no more

#106

Post by BoppreH »

I think one reason is because Make is built with Shell, which is always one step (and one letter) away from hell.

For example:

    clean:
         rm -rf *o hello
Did you really mean to erase all files and directories that end in "o"? Let's say it's just a typo and fix it: "*.o".

Now, are you sure it'll handle files with spaces in the name? What about dashes, brackets and asterisks? Accents? What if a directory ends in .o? Hidden files?

This specific case may support all of the above. But if it doesn't, what will happen? How long until you notice, and how long still to diagnose the problem?

Just like I prefer static strong typing when developing non-trivial projects, the build system should be more structured. I agree endless reinventing is tiring, but it may have some credit in this case.

Re: Build Tools – Make, no more

#107

Post by twic »

josephschmoe wrote: post #37

I've never felt hindered by Gradle. Hindered by the fact I can't add an arbitrary github repo through Gradle? Yes. That seems like it should be solvable though...

Add an arbitrary GitHub repo to what? In what capacity? You mean as a source dependency, an artefact repository, what?

Re: Build Tools – Make, no more

#108

Post by username223 »

hhariri wrote: post #54
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.

In what way would my reading that blog post have been a better experience for me with your tracking cookies?

Re: Build Tools – Make, no more

#109

Post by mturmon »

Silhouette wrote: post #77
mturmon wrote: post #57

Earlier quoted context omitted.

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.

In my experience, make is coupled to Unix. Make is not coupled to C. However, implementations typically include magic that is heavily biased toward building C and C++ code. As someone who works on a lot of projects, some using those languages and some not, I tend to think it's rather too magical at times. Personally, I'd prefer to have that kind of magic explicitly stated in some standard file that comes with the too…

I think "magic" is much too loaded a way to characterize it.

The rule applicable to C pertains to building foo.o from foo.c. It amounts to two lines in a Makefile:

  %.o: %.c
          $(COMPILE.c) $(OUTPUT_OPTION) $
where COMPILE.c and the other variable is predefined to trivial values.

There are other rules useful for C++, and for yacc, etc., but they are just as simple.

You can cancel all the implicit rules with "-r", or cancel selected implicit rules by naming them in the Makefile like this:

  %.o : %.c ;
All this is in the make manual, which is quite good: https://www.gnu.org/software/make/manual/html_node/Catalogue...

Re: Build Tools – Make, no more

#110

Post by Xorlev »

This post rather misses that while Make is simple, making Make do all the things we're used to (e.g. Java dependency management) not as simple.

I'd like to think people have decided that it's easier to replicate the task part of Makefiles onto their environment as the simpler alternative to making dependency management and various other language-specific tasks available to make.

Post reply on HN