POV-Ray : Newsgroups : povray.off-topic : Unix shell : Re: Unix shell Server Time
3 Sep 2024 17:18:28 EDT (-0400)
  Re: Unix shell  
From: Warp
Date: 29 Jan 2011 10:43:44
Message: <4d4435b0@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Actually, the primary problem with makefiles is actually C's bizarre 
> >> #include rules, where source files depend on other source files which aren't 
> >> evident from looking at the source files.
> > 
> >   Never miss a chance to belittle C-like languages.

> I'm not. I'm just pointing out why Make is so baroque.

  That claim doesn't make any sense. All IDE project files are like makefiles
(just with a different format). It's not like a makefile is somewhat special
and different from any project file.

> The fact that all the 
> stuff in the makefile is something you can't automate,

  What do you mean you can't automate? Of course you can. There are tons of
tools to automatically create makefiles (and makefile rules).

> and which in practice 
> you wide up actually having to compile everything twice, the first time just 
> to create the makefile.

  You don't need to "compile" anything to create the makefile rules. You
simply need to run a subset of the C preprocessor in order to see what
includes what (this is, afaik, what gcc does when you run it with the -M
option). It's not like it's an extremely heavy operation.

  Besides, you only have to create the rules once. If the dependencies
don't change, you don't need to create them every time you want to compile.

> Even *you* have to admit that nested #include files located solely via 
> environment variables is not the best way to manage type information at 
> compile time.

  I didn't understand anything in that sentence.

-- 
                                                          - Warp


Post a reply to this message

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