Re: importing files

[Frank Smith]

--On Wednesday, March 16, 2005 15:53:09 +1100 Tim Nelson 
<architect@webalive.biz> wrote:
>       I've only been skimming, and I thought that someone had already 
> explained, but in double-checking, they haven't.
> 
> http://www.iu.hio.no/cfengine/docs/cfengine-Reference.html#import
> 
>       The relevant section is:
> ---------------------------------------------------
> Note that, if you define variables in an imported file they will not be 
> defined for operations in their parent files. This because cfengine reads in 
> all the import files after the main file has been parsed - not at the place 
> where you call import in
> your script. This means that variables or macros defined in imported files 
> are only defined after the main program. Variables from earlier files are 
> inherited by later includes, but not vice-versa.
> ---------------------------------------------------

I've always wondered what the reasoning behind this design decision was.
Why not parse the imports the way most language preprocessors and applications
parse includes; where the end result is exactly the same whether you have
one big file or a smaller file including several other files (or even trees
of files)?
   Since the goal is to ease the work of system management, why extract a
penalty of extra thought and testing when you decide that part of your config
would be more manageable if it was split into logical subconfigs?
   My config has grown over time as I make more use of cfengine, while the
complexity of my systems has also grown, and splitting the config as it grows
requires more work than I think it should to avoid inadvertently breaking it.
   Perhaps there's a benefit of the current approach that I don't see.  If so,
I'd like to know what it is.

Frank

--
Frank Smith                                                fsmith@hoovers.com
Sr. Systems Administrator                                 Voice: 512-374-4673
Hoover's Online                                             Fax: 512-374-4501