Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Besides, I thought you don't like C either.
> 
>   The issue was the #include scheme, which you seem to hate and I really
> can't understand why.

Experience! :-)

I have explained it numerous times, with specific examples and general 
descriptions, so I'm going to assume it's one of those things you just won't 
ever understand. I think sometimes you fail to understand things that you 
disagree with.

>   Firstly, that doesn't answer the original question. It's not like Andrew
> was making a choice of programming language for his next project. He just
> wanted an easy way to compile a bunch of programs. Your answer doesn't help
> his problem in any way.

It does.  "Make is not appropriate for your task." :-)

Granted, the conversation has progressed since then.  But the basic comment 
was "by the time you need make, make will be inadequate to the task." Then I 
explained why, which is what we're arguing about now.

>   Secondly, what is it exactly that allows other languages to compile only
> what has changed, rather than everything every time? Right: The compiler
> keeps track of changed files and compiles only what has changed.

Sometimes. Other times, not. When it *is* the compiler doing it, it's using 
a dependency analysis more sophisticated than just file timestamps, which is 
all that make supports.

>   In a unix system this tracking has been separated into its own set of
> tools, rather than being part of the compiler. 

Except for, you know, that pesky -M switch. That's what I'm talking about. 
The tracking *is* built into the compiler. It would be a pain in the butt to 
use make to track dependencies without it being built into the compiler.

> *That* is essentially what
> you are complaining about. In other words, the C/C++ compilers doesn't do
> everything out-of-the-box, but instead you need additional tools.

Nope. Other languages have separate tools too. It's just built into the 
compiler for simple cases.

>   Well, if you don't like it, then don't. 

And *that*, my friend, is how this discussion started. Andrew asked about 
make, I said "You won't like it, so use something else", and you got upset 
that I explained why he won't like it. :-)

>   You are, hence, barking up the wrong tree. It's not the programming
> language that is the "problem". It's the separation of compiler and
> dependency file system that irks you.

No, it's the inability to correctly figure out dependencies based on the 
source files that's really the cause of the troubles.

>   That's right. You are putting the blame on the programming language,
> when what really irks you are the unix compiling tools. 

We were talking about make. I said "make was designed to deal with C's 
#include mess." The fact that there are other tools that deal with C's 
#include mess better than make does doesn't mean C's #include mess is less 
messy, nor does it mean that make is the right tool for dealing with other 
dependency issues. Which is what we're discussing.

 > You just love
> to hate C, so you just can't miss an opportunity to bash it.

I actually like C. It just has a number of legacy flaws, one of which is 
using #include instead of having actual compiled declarations stored anywhere.

>   Obviously a compiler cannot know all this if you simply give it a list
> of all the source code files. It needs slightly more elaborate rules.

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. (At least, not without 
writing the -M equivalent for your personal processors and remembering to 
run it when you change the list of frames.)

You can achieve it with a makefile, yes, but primarily not by having the 
dependency stuff going on, but by building them as different projects. That 
is, one tends to have a top-level makefile that says "first run make on the 
content generator, then run make on the content, then run make on the 
packaging directory."

Maybe it's just because every single makefile I've ever seen in my entire 
life really, really sucks and doesn't work right either that I'm down on make.

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