Re: cons for modular packages

[Steven Knight]

On Sat, 2 Dec 2000, Axel Hecht wrote:
> I'm quite new to cons, that is, I read the doc, and found some errors in
> the FAQ ;-).

Welcome aboard.  The FAQ is definitely out of date; I'd welcome any
reports of errors that you spotted so they can be corrected as soon as
time allows.

> 1) cvs support. I found the Repository command in cons, but this is (am
> I right?) only for local repositories, cvs access for needed files would
> be cool.

Correct, the current support essentially assumes a Repository is an
already-checked-out snapshot of the source tree.  If a Repository contains
any derived files (targets), Cons assumes that they're up-to-date with
respect to the Repository source files.

CVS support probably wouldn't be extraordinarily difficult to add.
(Hey, it's only software, right?)

> 2) For building software, that depends on several modules, special
> targets would be great. The mozilla build system has something like
> this, called modules. The file based approach wouldn't really cut it
> here. A big issue is, that people wouldn't want the complete gnome
> repository, or mozilla sources, or whatever on their disk, just to find
> out how to build the header of one rather good defined module.
> Additionally, the module name is not always a file or directory name
> (SeaMonkey in case for mozilla, that's not in a single filename)
> I think of something like this: you wanna build koffice, so you pull the
> main Construct, and build the 'module' (I stick to this term, I know
> it's used differently in cons) "KOffice". So Construct would pull the
> module list, check the dependencies, pull kdelibs and kdecore and
> whatelse, and builds all those in one go. Finally you can go to bed
> while doing this stuff, you don't have to start building a package every
> 20mins. ;-)

There's a proposal on the table for an Alias command that would allow
for expansion of special (non-file) target names to a list of targets.

For mozilla's purposes, would it be sufficient to support Aliases
(special targets) like this only on the command line?  Or is it necessary
to establish large-scale dependencies between special-target subsystems
by specifying them within the config (Conscript) files?

> 3) developers of extensions or plugins don't need the standard package,
> so is there a way to give a target to the Build command?
> Like Build qw( HugePackage sdk );

I understand what you're asking for generally, but am not sure what you
would expect your example Build command to accomplish.

Be aware that the Build command is slightly mis-named (IMHO), and
doesn't actually build anything.  It really means, "Read these subsidiary
Conscript files for dependency information."  What actually gets built or
not comes completely out of walking the dependency tree for the targets
specified on the command line (or via the Default method).

> 4) are there any attempts to port cons to the mac? I found the ':' to be
> of heavy use, which is the pathstep separator on MacOS (like '/' on
> unix, '\' on windows).

There are no active Mac ports currently, but we've been moving in the
direction of more and more portability over the last several releases.
The portability between UNIX and Windows NT right now is very high.
All path name manipulation uses an internal clone of the standard Perl
File::Spec module for portability.  Almost all of the places where ':'
is used as a separator take an array reference as well, so lists can
be specified without relying on any OS-specific separator character.
Unfortunately, the documentation hasn't been gone through and updated
to reflect this, so it reads like there's more dependence on ':' than
there really is at this point.

> 5) how about support for configure like feature tests? 

There isn't any special support for testing, but Cons can be used very
easily for executing tests.  The way that people trying to run tests
under Cons generally do it is to log test output to target files,
and create appropriate dependencies between finished products, test
scripts, and the test logs.  Depending on how you structure your tree,
you can create very powerful and fine-grained testing infrastructure,
especially if you use the variant build support.

> Alot of questions, I see. I hope you find them usefull.

Very much so.  I'd be pleased to help with anything that would make it
more attractive to use Cons to build all or part of mozilla.  Say the
word.

        --SK