Re: cons for modular packages

[Axel Hecht]

Hi Steven,
thanx for putting my mailing to the list. If as cite ;-).
Configured another client (mozilla ;-)) to the other email address

Steven Knight wrote:

> On Sat, 2 Dec 2000, Axel Hecht wrote:
>
> > <...>
>
>
> > 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).


I'll respond to 2 and 3 together, as it's basically the same problem.
The Alias thing looks good, but there should be a way to tell cons, which
Conscripts talk about which targets. To me, Alias could be a way to generate
interfaces between build parts. To give a concrete example:
Let's start with the mess I'm in. I'm doing the build stuff for an 
extension to mozilla,
called transformiix. There is a plugin version, as well as a standalone.
The standalone needs only the build system, the plugin needs the layout 
headers, too.
(those depend on a whole lot, but not on other extensions, mailnews, 
editor, yadda, yadda)
mozilla has currently one entry point, pulling the appropriate parts of 
the tree (some
parts need a branch tag), and building the appropriate modules. (at 
least we have that
on unix)
So there is one file, telling the build system which  module needs which 
modules as
well as how to pull/build those.
(Why we should switch? Because we are in heavy trouble for cross 
directory targets!
And we need niceness on windows, too.)
So having one file, telling which Conscript describes a Alias would be a 
great thing.
The basic problem would be a (neat) way to conditionally add Conscripts 
to the build.

I guess, it could be done with having Alias, but I don't have in my 
head, whether this
would look like a mess. And mess is error prone :-(

> > <...> other thread, and I hope for my MacHead to return to office soon.
>
>
>
> > 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


.. or two ;-).

Thanx so far

Axel