[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cons for modular packages
From: |
Dean Roehrich |
Subject: |
Re: cons for modular packages |
Date: |
Mon, 04 Dec 2000 13:13:54 -0600 |
>From: Axel Hecht <address@hidden>
>Hey, I got another name:
>Buildscope
>Opposing to Build or Build_Scope, it's not as easy to be taken as a
>verb, and it speaks
>quite frankly about what is new in the file that is named.
When I hear Buildscope I think you're stressing scope (ok, you are). The only
thing that is limited to the scope of that sub-Conscript is the Perl
environment variables, and so I think you're stressing the wrong thing. The
sub-Conscript is about the dependencies and build rules it contains; it's not
about the Perl variables that are used within it.
Maybe Project(), or Subproject(), is something to consider. Each
sub-Conscript file is a project or subproject of the whole. Again, this
doesn't tie the locations or responsibilities of the sub-Conscript files to
the directory structure of the source tree. It gives you a hint that each
sub-Conscript might have some purpose that has nothing to do with "you're
responsible for everything in this directory".
Ah, then multiple sub-Conscripts within the same directory are going to be
common practice--even when they're tied to the directory structure ala current
practice. Then the word "Conscript" will become a filename prefix, rather
than a whole filename itself.
Dean