[xen-tools] Re: More changes

[C.J. Adams-Collier]

On 9/4/07, Steve Kemp <steve at steve.org.uk> wrote:
>   Again I don't see why that is necessary.  I have no plans to
>  distribute to CPAN, nor do I think it is a useful thing to do.

I personally find it a useful thing to do.  apt-get install xen-tools
is nice, but it would like to be able to use this module from other
distributions.

>  Certainly if installing the package places the library files
>  into the correct location that should be fine for you in
>  your use case, and it avoids fragmentation and overhead.

I don't want to cause fragmentation or overhead.  Let me know where
the problem is and I'll try to address it.  The new Build.PL and your
Makefile are not mutually exclusive.  They should both be able to
function separately with no problem.

>   e.g. How do I update META.yml?  It seems like that would be
>  a pain to do prior to release.

No need to have one.  'perl Build.PL && ./Build dist' will generate
one as Xen-Tools-$version/META.yml

> > You may be asking yourself why we would want a CPAN-style build system
> > at all.
>
>   Exactly.
>
> > I guess the answer might be that having a build system that
> > complies with the standard Perl distribution mechanism buys the
> > project support from the community and integration with the CPAN
> > Testing Service and listing in the CPAN registry.
>
>   I think, ahem, that we already have community support.

Sorry, I didn't mean to imply that you did not have support from
members of the CPAN community.  I meant more in the sense of
integration into the CPAN community's build environment and compliance
with best practices.

> > If a handle is kept to a single running libperl instance, the overhead
> > of exec()'ing the binary is only incurred once.  The handle could then
> > be issued requests as needed.  This would only incur an in-process
> > stack push rather than a call to the kernel for memory allocation,
> > process creation, etc.  If libperl supports threads, the overhead
> > could be reduced even further.  But I'm getting out of my depth at
> > this point :)
>
>   OK, noted.
>
> > Good to hear.  If the lib/ patch is applied, I'll remove that tarball anyhow.
>
>   I've just mailed you separately, but if the Makefile stuff were
>  removed I'd apply it immediately.

Oh, sorry... I wasn't clear.  The Makefile stuff has been removed.
I've decided to use Ken Williams' wonderful Module::Build instead.  No
make required.

> I'd be keen to drop the use of
>  Moose (hey that rhymes!) but I could live with it if there were
>  a good reason for it.

Well, Moose provides an object model that is becoming standard as well
as some fancy features like an argument validation system, object
attribute constructors and class creation helpers.  It reduces the
KLOCs substantially and IMHO, makes the code much cleaner.

Another benefit is that I expect to write the C binding using the
Moose object model.  The Moose and glib object models are similar
enough that it should be easy to write a c -> Moose caller library
relatively easily.  This would open all classes that inherit from
Moose to being called from C.  Python, Perl, C++, C# and basically
everything else can call C, which means that they would be able to
call Moose object methods without the overhead of process context
creation.  Rolling our own object model (or worse, doing it ad hoc)
would make it much more difficult to write xen-tools apps in different
languages than Perl.

> Steve
> --
> http://www.steve.org.uk/

Cheers,

C.J.

-- 
moo.