|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |