Darren New <dne### [at] sanrrcom> wrote:
> 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! :-)

  Or lack thereof, it seems.

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

  It just looks to me that whenever there is a problem with something,
you just love to blame it on C/C++ if it's somehow involved.

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

  And which tool, exactly, did you recommend instead? I remember you
mentioning shell scripts. Yeah, those can track dependencies just fine.

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

  It's actually in the C preprocessor, which is a separate tool.

  You *could* have a separate dependency rule creation tool that does
nothing else. On the other hand, it was easier to add that to the C
preprocessor, so they did that.

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

  So when other languages have dependency rule generation built in, it's ok,
but when the C compiler has, it's somehow not ok.

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

> And *that*, my friend, is how this discussion started.

  In other words, you didn't answer his question, which is my point.

> 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. :-)

  And what exactly is that "something else"? How was your answer helpful
in any way?

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

  So now you are changing the argument. First the problem was that you
need a separate tool to generate the dependency rules, but now the problem
is "the inability to *correctly* figure out dependencies", whatever that
means.

  Which tool incorrectly figures out the dependencies?

  Why does it feel that you are desperately trying to pile up more and more
perceived problems to the issue?

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

> I actually like C.

  You are certainly making a very good job at hiding it.

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

  I don't get it. That's exactly what you do with make, which was exactly
my point (and exactly why I'm comparing it to the "project files" of other
IDEs).

  You seem to be desperately trying to find flaws that just aren't there.

  Maybe what irks you is that with makefiles you need to write a bit more
syntax to get the same effect.

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

  I suppose you could do that, but I don't think it's necessary.

-- 
                                                          - Warp

Post a reply to this message