Re: RFD: CVS or Arch?

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> 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))'
>
Yeah, just saw that lately.

> 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..)
>
It would be good for dev-environ to work with separate build dirs
anyway, IMHO.

> 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 think it should be possible, but I don't really see why we should do
that, since they have prefixed gw- anyway.

> 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 sounds like a good idea, putting scheme code providing
non-wrapper related functionality in a separate namespace.

> 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...)
>
What exactly do you mean/object to with "POSIX in the main namespace"?
I guess you refer to guile-gnome having to shadow core 'connect' and
the like? I mostly solved this issue by only dot-prefixing generics,
if the original thing (procedure) can't be upgraded to a generic
(which works in every case except when the method to be added isn't
specialized). Code is in g-wrap--rotty--1.0 (g-wrap-runtime.c).

>> 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.
>
I thought rather about generating configure.in than the Makefile.am:s,
so that every module provides a "configure snippet" that outlines what
modules out of guile-gnome it builds upon and what other stuff it
needs, and autogen.sh then creates a configure.in out of the snippets
and a template. And yes, I intended to dribble this ball and hopefully
dunk it ;-)

Rotty
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.