POV-Ray : Newsgroups : povray.off-topic : Unix shell : Re: Unix shell Server Time
3 Sep 2024 23:23:53 EDT (-0400)
  Re: Unix shell  
From: Warp
Date: 31 Jan 2011 16:30:53
Message: <4d472a0c@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Never miss a chance to bash C.

> I don't understand how me describing a problem that caused me not to like 
> certain features of C is "never missing a chance to bash C."

  The discussion was about makefiles and resolving include file dependencies,
and as a "side note" you mentioned how some #defines can mess up code
really badly in C.

  Yes, I know that you can create really, really obfuscated code in C by
abusing the preprocessor, and that there exists lots and lots of C code
out there that abuses this to horrendous extremes. How is this related
to the question of makefiles?

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

> OK, at this point, you're just refusing to understand what I'm saying.

  You are saying that 'make' cannot know which files something depends on
unless you tell it (eg. by manually listing the files or by using a tool).
I'm saying the same thing. What is it that I'm not understanding?

  The difference is that you are somehow expecting 'make' to know about
a myriad of file formats and how they are used and how they depend on other
files, while I'm saying that 'make' is a generic tool, not a tool specific
to certain programs or file formats. You don't like 'make' being a generic
tool.

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

> Not really. Make only handles it if I manually duplicate that information 
> into a different format.  If I add something to the XML and not to the 
> makefile, it's not going to work any more.

  So your complain is, once again, not about makefiles per se, but about
the need to use tools to automatically create and update the dependencies.

  How would you enhance the whole makefile process so that it *would*
conform to your needs?

> Are you telling me that the need for duplicating that sort of information is 
> a *good* idea? Or do you admit that needing that information in two 
> different places in two different forms is indeed a limitation that it would 
> be desirable to eliminate?

  Exactly how would you eliminate the need?

  What happens if you have a custom format which has similar kinds of
dependencies? How do you expect it to work then?

  You still can't get over the fact that 'make' is a generic tool.

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

> And you know what? There will never be such an alternative by folks who 
> think that anyone pointing out a limitation with their tools are simply 
> bashing for the sake of bashing.

> That said, there are many alternatives to make, some of which even generate 
> makefiles as output.

  So you do and don't oppose the idea of using third-party tools to generate
the dependencies. Double-think?

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.