Re: RFD: CVS or Arch?

[Andy Wingo]

Good day to you, or evening, or what-have-you,

On Fri, 2004-01-16 at 23:57, Andreas Rottmann wrote:
> Andy Wingo <address@hidden> writes:
> >     but I have problems committing changes when I build in the
> >     source tree
> I always use separate builddirs (especially since I started using arch
> ;-)). You can't really run in-tree anyway, since the gw-* shlibs need
> to be installed, I think. 

Perhaps you didn't notice the dev-environ scripts at the top of the
source trees?

$ ./dev-environ guile -s '(use-modules (gnome gtk))'

I really don't want to have a separate builddir. I wouldn't mind for C,
but because the scheme files don't need compilation it makes it a pain.
arch shouldn't change everything about the way I work :)

But OK, for now I'll just add in the necessary stuff to dev-environ to
make it work with ,,build or something. (`=' isn't too shell-friendly..)

> Hmm, I didn't say we should release 20 tarballs, but in the light of
> the changing scope of the modules to be considered in the GNOME
> developer platform and the implications wrt. the Bindings release set,
> I think it would be nice to be flexible enough to be able to deliver
> any configuration, going from a big tarball, containing all of
> guile-gnome, to (not that we ever need to do this) having a separate
> tarball for each upstream module.

Yeah, you're probably right.

I'd also like to comment on your proposal[1] more specifically:

[1]  http://stud3.tuwien.ac.at/~e9926584/GuileGnomeArchProposal.html

> Archive Layout
> Each binding for an upstream module will live in its own category

Fine. For the record, this would be the time to decide on how our module
tree should really look. (gnome pango), (gnome gtk), (gnome source-view)
sound like fine names to me. Can we put all the g-wrap libs in a
separate namespace? (gnome gw gw-gtk) or (gnome g-wrapped gw-gtk) or
(gnome gw gtk) or something. Thoughts?

I'd also like a category for scheme code. Like the REPL, and I've
written two custom generic treemodels: one that has lazy initialization
for values and children of nodes, and the other is a filtered list (you
can set its contents to be a list of anything, and you set a predicate,
and you subclass to implement on-get-n-columns, on-get-column-type, and
on-get-value). This code is useful and tricky to write, and it would be
nice to start a library of such routines. (gnome extra repl), for
instance. That is, if ^%$&^$ guile didn't prevent `repl' from working as
the name of a module. (And why is the name `app' still reserved even in
1.7? Grr... And POSIX in the main namespace... So much to do...)

> Build Infrastructure
> There will be a shared autogen.sh script that "cleverly" figures
> things out, so starting a full build should go something like this:

You mean the Makefile.am files get autogenerated? That's three
abstractions away from Makefiles ;) But cool, it can prolly work. I'm
punting that ball to your territory, though.

-- 
Andy Wingo <address@hidden>