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

The Language Agnostic, All-Purpose, Incredible, Makefile

blog.mindlessness.life

Post reply on HN
Print view View original

81–90 of 124 posts

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#81

Post by ur-whale »

de_watcher wrote: post #67
ur-whale wrote: post #9

Make is great as a dependency resolution engine. For everything else, it is absolutely horrible. What I typically do is use make only for what it is good: as a dependency resolution back-end. All the build logic for my projects is written in Python, in an executable file stored in the project root directory and called "make" (I have "." in my PATH). The Python script, when it runs, generates on the fly a clean, lean,…

This kind of projects always makes me sad: you've got to read and debug through an impenetrable wall of custom python code to understand why the build fails.

I guess you didn't read the part that says it generates a simple unrolled Makefile.

That's way more debuggable than the crap that ie configure generates.

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#82

Post by pif »

teddyh wrote: post #2

Make is great, and I wish more people would use it in place of whatever monstrosity is en vogue this week. However, there is one thing which Make absolutely cannot handle, and that is file names with spaces . If you have any risk of encountering these without any possibility of renaming them, you’ll sadly have to give up on using Make; it just won’t work.

File names with spaces is a sign of lousy developers and IT technicians. If you have file names with spaces you have already lost.

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#83

Post by gimboland »

pif wrote: post #82
teddyh wrote: post #2

Make is great, and I wish more people would use it in place of whatever monstrosity is en vogue this week. However, there is one thing which Make absolutely cannot handle, and that is file names with spaces . If you have any risk of encountering these without any possibility of renaming them, you’ll sadly have to give up on using Make; it just won’t work.

File names with spaces is a sign of lousy developers and IT technicians. If you have file names with spaces you have already lost.

Bwahahahahahaha! Good one!

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#84

Post by pjmlp »

enriquto wrote: post #58
colordrops wrote: post #53

Earlier quoted context omitted.

I can't tell if you are being sarcastic.

i am dead serious about that. Allowing the separator character in filenames is a nightmarish error.

Only for tools that are stupid for not being able to handle any kind of filename.

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#85

Post by [deleted] »

colordrops wrote: post #53
enriquto wrote: post #7

Earlier quoted context omitted.

I agree, and the solution to this problem is to forbid filenames with spaces. The convenience of make and similar tools is much more important than spaces in filenames. File names with spaces should not be allowed in modern filesystems. When the user types a filename with spaces, the GUI should encode the space as a non-breaking space character, that does not cause havoc in scripts.

I can't tell if you are being sarcastic.

[deleted]

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#86

Post by jacwah »

m463 wrote: post #66
kjs3 wrote: post #56

Earlier quoted context omitted.

Why is old bad? I can't tell you how often one of my team shows me some clever, non-trivial Python script that I solve in a couple of lines of awk/sed/perl. Or a small makefile. Why in the world would I want an OOP make? What do I need 'more sophisticated' in make statements that wouldn't really mean that I needed to be using a different tool that undoubtedly wasn't solving the problem make solves? OK...debugging cou…

I've used make extensively. I wish it had a little python in it. After using pathnames in awk/sed/perl I find using os.path in python gets rid of all the special cases due to quoting and escaping. Python has nice lists and dicts and sets too. For OO, I wish rules were a bit like python classes. It would be wonderful for say 10 c files compiling one way, and the 11th having a different option. Or overriding a few opti…

> It would be wonderful for say 10 c files compiling one way, and the 11th having a different option.

You can do this by combining implicit and explicit rules:

  target: $(OBJ)
  
  # default rule
  %.o: %.c
      cc -o $@ $^
  
  # special case
  special.o: special.c
      specialc -o $@ $^

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#87

Post by mmjaa »

teddyh wrote: post #2

Make is great, and I wish more people would use it in place of whatever monstrosity is en vogue this week. However, there is one thing which Make absolutely cannot handle, and that is file names with spaces . If you have any risk of encountering these without any possibility of renaming them, you’ll sadly have to give up on using Make; it just won’t work.

This is why I find detox to be such a handy tool:

http://detox.sourceforge.net/

Detox has solved endless amounts of hassle...

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#88

Post by teddyh »

m463 wrote: post #66
kjs3 wrote: post #56

Earlier quoted context omitted.

Why is old bad? I can't tell you how often one of my team shows me some clever, non-trivial Python script that I solve in a couple of lines of awk/sed/perl. Or a small makefile. Why in the world would I want an OOP make? What do I need 'more sophisticated' in make statements that wouldn't really mean that I needed to be using a different tool that undoubtedly wasn't solving the problem make solves? OK...debugging cou…

I've used make extensively. I wish it had a little python in it. After using pathnames in awk/sed/perl I find using os.path in python gets rid of all the special cases due to quoting and escaping. Python has nice lists and dicts and sets too. For OO, I wish rules were a bit like python classes. It would be wonderful for say 10 c files compiling one way, and the 11th having a different option. Or overriding a few opti…

> I wish it had a little python in it.

GNU Make can have Scheme in it:

https://www.gnu.org/software/make/manual/make.html#Guile-Int...

Re: The Language Agnostic, All-Purpose, Incredible, Makefile

#89

Post by zwegner »

robochat42 wrote: post #77
zwegner wrote: post #34

Earlier quoted context omitted.

Yeah, I know about Bazel, but only at a high level--I haven't used it. I generally think the hermetic build concept is a very good one, but IMO Bazel goes about it the wrong way, and is overengineered. Rather than needing custom-built infrastructure for every type of language supported, I'd prefer build systems to use lower level OS facilities for discovering dependencies and controlling nondeterministic behavior. Th…

There are build systems that use strace to find dependencies. For instance tup [1][2] and Fabricate [3]. Also see this post by Waf which discusses some issues with this approach [4] [1] http://gittup.org/tup/ [2] https://news.ycombinator.com/item?id=12622671 [3] https://github.com/brushtechnology/fabricate/wiki/HowItWorks [4] https://waf.io/blog/2015/02/using-strace-to-obtain-build.htm...

Ah, thanks for the references. Now that you mention them, I realize I definitely knew about tup and fabricate before (and possibly waf?), but had forgotten about them. I haven't really thought much about trace-based build systems in years, until this subthread.

And looking through that waf blog post, I realize that I meant ptrace instead of strace--I want full fine-grained syscall interception, not just a text report afterwards. That gets around a lot of the overhead/parsing problems mentioned, and is required for the "pause build command so its input file can be built" case.

Post reply on HN