"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
> > This is an ancient trick I learned decades ago ;-). The form
> > _GRANITE_FILE_INC_ (the last underscore is maybe redundant) somehow
> > covers all the possible forms of writing (capitals, dots, etc) of which
> > a file name is composed. And it works perfectly well for me.
>
> You're killin' me.
> I have never seen this used before, or even mentioned.
> Is this in the documentation?
>
> > And then...!!!! [thunderclap]
> > So I forgot to give you the proper Line 70, which should be of course,
> > after Line 69, as given:
> >
> > #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
> > "DakotaRedGranite.inc"  #end
> > #include Granite_file
>
> So I guess I will have to play with this...  is the _GRANITE_FILE_INC_
> "operating on" the #local Granite_file declaration ...?  Does it need the _INC_
> part then...?
>

This is a lifting of a "protection" mechanism from the C language (at least
that's where I first encountered it).

The basic form is in your main .c file is:
#include <somefile.h>
#include <someotherfile.h>

Assume that somefile.h also includes other files, and those include others.
Further assume that someotherfile.h also includes other files.  If it ends up
that some set of includes is /duplicated/ then you run into problems.

So, to avoid that, in C somefile.h will contain something like this:
/* file: somefile.h */
/* defines some stuff */
ifndef(_SOMEFILE_H_)
 #define _SOMEFILE_H_
 #declare bob=1
 #declare ted=2
#end

The idea is that each include file defines the variable name associated with
that file, so that if that include file is hit /again/ when resolving includes
the first ifndef line will discover that, the include file contents will be
'skipped', and nothing /more/ will happen.

I'm not aware of any 'magic' that happens in povscript WRT defining a
_filename_INC_ variable, but there could be such.

(hope this helps clear up the concept)

Post a reply to this message