Darren New <dne### [at] sanrrcom> wrote:
> >   Anyways, exactly why would you want to recompile your program if stdio.h
> > changes? You see, stdio.h is standardized, and if it was changed in such
> > way that programs would need to be recompiled for them to work, it would
> > mean that the C standard has been changed to be backwards-incompatible and
> > it would break basically all programs in existence.

> Nope. All I need to do is redefine O_RDWR to have a different value or 
> something like that. (OK, not stdio.h, because that's very modularized.)

> Or, if you want, errno.h or any of the other less-well-thought-out include 
> files.

  And you would immediately break like every single program in your system.
Way to go. (And please don't claim that you don't know why they would break.)

> Of course, if someone comes along and does a #define in some include file 
> that conflicts with something in stdio.h, then you're screwed too. Ever 
> spend three days trying to figure out why putting

>     extern int write(int,char*,int);

> at the top of your source code so you could print some debugging info throws 
> a compiler error saying "too many close braces"?

  Never miss a chance to bash C.

> >   Make can't know if eg. a code-generating program depends on some data
> > files unless you tell it.

> Yep! And there's the problem.

  The problem is that 'make' cannot read your mind, it seems.

  Of course it cannot know which files a something depends on unless you
tell it. Seems rather obvious to me.

> Right now, for example, I have an XML file I use to specify the levels for 
> my game. In those XML files I include the lists of animations going on in 
> different places, the textures, etc etc etc.

> Know what? Make doesn't handle that.

  Sounds like something 'make' was specifically designed for.

> Know what else? The tool I'm using 
> does, because as I compile that XML file into the internal format, I'm 
> telling the build system "By the way, the results of compiling this XML also 
> depends on that texture, that sound effect, and those two animations."

> If I were to try to do this with Make, I'd either be repeating all the 
> information manually, or I'd have to write a program to parse that XML file 
> and pull out the appropriate dependencies, except output them in a different 
> way.

  You are constantly shifting the goalposts, and don't seem to be able to
decide if you want to bash makefiles or C, whether what you want is
impossible to do with makefiles or simply more laborious, whether the
problem is that what you want to do is not possible solely with 'make' but
instead you need a third-party tool, or what.

  Sometimes it's "make sucks because of the include file system in C",
sometimes it's "make sucks because it can't do this", sometimes it's
"make sucks because while you can do this, it's more laborious than with
this other fancy tool I have", sometimes it's "make sucks because you
need to use the compiler to generate dependencies".

  You don't seem to understand that 'make' is a generic tool. Or more
precisely, you don't seem to understand what the word "generic" means.
You seem to think that it should mean "supports all programming and
markup languages in existence out-of-the-box, and is able to read your
mind". That's not what "generic" means.

  You have made it abundantly clear that you don't like the fact that
you need, oh gosh, third-party tools if you want to automatically create
dependency lists for some specific file formats. "Hey, I have these files
in this format, and I have this specialized tool that tracks dependencies
on them automatically, and 'make' cannot do that automatically, hence
'make' sucks." Way to miss the point.

  And the best part of all this? So far you haven't given even a single
alternative that would do everything that 'make' does and is better by
your definition (whichever that might be). And preferably one that can
be run in most systems.

-- 
                                                          - Warp

Post a reply to this message