Warp wrote:
>>>   And which tool, exactly, did you recommend instead? I remember you
>>> mentioning shell scripts. Yeah, those can track dependencies just fine.
> 
>> Indeed they can, when you don't have nested dependencies.
> 
>   "Indeed thay can"? Shell scripts don't have any kind of dependency
> tracking whatsoever. I think you are somehow splitting hairs with
> terminology.

Sure. There's /bin/test for stuff like that, if you really care to do that. 
The idea that Andrew is writing C systems big enough to worry about compile 
time while not already have a makefile built for them is kind of unlikely, 
methinks.

>   Ok, you could write a 'for' loop which goes through a list of .c files
> and compiles them (resolving the name of the executable by removing the
> ".c" part) and put all that in one line, 

Yeah. It's one line.

for i in (*.c); do gcc -o ${i%.c} $i; done

(Something like that. Untested.)

Hardly a hulking line.

> "One-liner" usually refers to being able
> to express the task with one single command (a 'for' and its body are
> usually considered separate commands).

Now you're picking nits again, just like with your arguing that "gcc -m" 
isn't invoking the compiler.

>   Perhaps what you meant was one line per program. That could probably
> work for what he wants to do, if he doesn't mind that *every* program
> will be recompiled every time he wants to recompile just one of them.

No. Right there, above. What is that, 40 characters if that?

And how long would it take to compile *every* program that Andrew has 
written in C on a modern machine? If he saved as much compile time over the 
course of his development as he spent reading the manual for make, I'd be 
surprised.

>   The advantage of that over having a separate shell script for every
> single program? 

Your shell scripting skills must really, really suck if you think you'd need 
a line of shell code for every single program. Just sayin'.

>   If you want to compile only one single program, or automatically compile
> only the programs that need to be compiled, the *easiest* way is to use
> a makefile. A shell script would be significantly more complicated. 

Show me a makefile shorter than that line up there.

If you really want to worry about dependencies:

for i in (*.c) ; do if test $i -nt ${i%.c} ; then gcc -o %{i%.c} $i ; fi ; done

OK, that one wrapped. Still not significantly more complicated, especially 
if you already know bash but don't already know make.

>   Which is BS. You seem to think that you can't create a makefile that
> compiles programs without the dependency lists. It's not like you are
> forced to provide them.

I don't remember. Do you have to actually list the programs in the makefile 
that you want to compile?  Is a makefile that compiles 50 programs 
necessarily larger than one that compiles 5?

>   Creating a shell script for this is the hard way.

It's not hard. It's trivial. I wrote both of those off the top of my head 
without looking anything up. They're *equally* trivial.

>> No. The programming language is such that it is impossible to figure out by 
>> looking at the source code what the dependencies are on other source code. 
> 
>   If that were true, then it would be impossible to compile the program.

No, because you provide more to the compiler than the source code.

> After all, it's impossible for the compiler to figure out which files are
> being included just by looking at the source code.

Yes it is. That's why you have -I and -L command-line switches.

>   I suppose compilers do it by magic, then.

Nope. Compilers look at stuff that isn't in the source files.

>   Besides, you *are* changing the argument. First it was "make cannot figure
> it out on its own", 

That's correct.

> then it was "it's not possible to correctly figure out
> the dependencies" (whatever that means, as I still don't get it).

... from looking at the source code.  You keep leaving that bit off.

>   Why does it feel like you are desperately trying to find problems and
> just can't seem to be able to decide what the actual problem is?

Maybe because I'm trying to explain an elephant to a blind man who refuses 
to believe it even exists?

>>>> Yet, oddly enough, that's precisely what the XNA content pipeline does, and 
>>>> you just give it a list of all the source files, including the graphics and 
>>>> audio and stuff. Sure, you mention the name of the code used to compile it, 
>>>> but there's enough information from that to track down where the executable 
>>>> and such is. It also makes it possible for the thing that's compiling your 
>>>> collection of frames into an animation to say "the resultant animation 
>>>> depends on this list of frames as well as the text file specifying the list 
>>>> of frames", which you can't do with a makefile.
>>>   I don't get it. That's exactly what you do with make,
> 
>> Nope. It's not what you do with Make, any more than writing C++ code is the 
>> same thing you do when writing C code.
> 
>   Maybe *you* don't use 'make' for that, but I do.

OK. You're just refusing to read what I actually wrote, and refusing to see 
the fundamental difference in the two tools.  I can't tell whether you're 
doing this intentionally out of ego or what.

>   I wrote an example earlier: Suppose you have written a program that
> generates code, and it generates the code from some data files. Obviously
> you would want the program to be run if (and only if) some of those data
> files change. Exactly which automated tool would you use to do this?

Well, as I said, the XNA content pipeline does exactly that, precisely 100% 
word for word that. And yet, oddly enough, I don't manually duplicate the 
dependency information into a separate file.

Or, if you really wanted to knurl your gears, you could imagine a tool that 
runs the compiler (or whatever program you specified) and uses strace to 
track what files it opens for reading and what files it creates, and from 
that track dependencies automatically. This would work with any tool, would 
automatically track every dependency (perhaps too much, granted), and would 
not need anything changed in any tools you use. But that would be admitting 
that make has some limitations.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message