RE: cons for modular packages

[Alex Jacques]

Ok, I'll enter the name contest (is there a prize? - yes, a free copy of
Cons!, with source included!).

How about simply calling it Conscript(), after all it does run
Conscripts, and this term is used throughout the manual. Furthermore it
doesn't try to nail down exactly what a Conscript is/does. That's
probably too varied and/or involved to describe any better in something
as short as a function name.

Speaking of deprecating features: might I suggest that if certain
features become deprecated, that there be a command line switch that
causes Cons to issue warnings when deprecated features are used. That
way people can continue to use Cons with older Construct/Conscript
files, but easily find out what deprecated features they're using
if/when they decide to update their files. Personally I've always found
this difficult, frustrating, time consuming, error prone (insert
additional adjectives here) to do simply by reading the manual and
looking over my files. This sort of optional warning should be easy to
implement:

sub Conscript {
    # all the good code currently in Build()
}

sub Build {
    warn "Build() is a deprecated function - see Conscript()"
          if $param::warn_deprecated;
    &Conscript;  # call Conscript w/ Build's arg list
}

-----Original Message-----
From: address@hidden [mailto:address@hidden
Behalf Of Dean Roehrich
Sent: Monday, December 04, 2000 2:14 PM
To: address@hidden
Subject: Re: cons for modular packages

>From:  Axel Hecht <address@hidden>

>Hey, I got another name:
>Buildscope
...
When I hear Buildscope I think you're stressing scope (ok, you are).
...
Maybe Project(), or Subproject(), is something to consider.
...