[xen-tools] Re: More changes

[C.J. Adams-Collier]

On 9/2/07, Steve Kemp <steve at steve.org.uk> wrote:
>   I don't see why this is necessary .. It seems that you're
>  agreed with my point of merging the library code into the
>  xen tools repository / directory.

Indeed.

>   If that is the case then we don't *need* to have Makefile.pl,
>  we can do the installation with the Makefile.
>
>   ie. I don't see that we need:
>
>     Make -f makefile install   (install docs + bin/*)
>     perl Makefile.pl           (generate Makefile for module)
>     make install               (install lib/*)

Sorry, I guess I wasn't clear.  It would be:

make (output list of supported targets, as is currently done)

perl Makefile.PL (generate CPAN-style Makefile)
make -f Makefile (build blib/ directory)
make -f Makefile test (run Test::Harness test suite as defined in
CPAN-style Makefile)
make -f Makefile dist (build a tarball for distribution on the CPAN)

However, after thinking a bit more about it, we can probably avoid the
whole MAKE(1) issue by having the CPAN dist handled by Module::Build.

http://search.cpan.org/~kwilliams/Module-Build-0.2808/lib/Module/Build.pm

You may be asking yourself why we would want a CPAN-style build system
at all.  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.

http://cpants.perl.org/
http://cpants.perl.org/dist/Test-Harness (example distribution statistics)
http://search.cpan.org/

> > Steve, you mentioned earlier that you could not see a use case for
> > external programs linking to libraries from xen-tools.  This is
> > exactly what I intend to do and the reason for my interest and
> > contributions.
>
>   I think I said it seemed unlikely; but I'd also guess that
>  unless you add in some feedback API you're not gaining much
>  with that approach:
>
>     exec( libperl ...  )
>    vs.
>     exec ( xen-create...)

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 :)

http://search.cpan.org/dist/perl/pod/perlembed.pod#Maintaining_a_persistent_interpreter

> > Steve, do you mind me mentioning this work in my blog?
>
>   Not at all :)

Well then.  Maybe I'll put something up there in the near future  Keep
your eyes on

http://wp.colliertech.org/cj/

> > You had
> > mentioned before that you were concerned that I was not giving credit
> > where credit is due, and I would not want to reproduce that feeling of
> > ill will.
>
>   You won't.  As far as I'm converned when you uploaded a fixed tarball
>  that was solved.

Good to hear.  If the lib/ patch is applied, I'll remove that tarball anyhow.

> > Let me say for the record that I feel that this codebase is an
> > excellent piece of work, and that I appreciate all of the hard work
> > that Steve and the team has contributed.
>
>   Thanks a lot from all of us.  (Just ignore the bad code, which is
>  mostly mine :)

Heh.  I've written my share of bad code.  I'm sure I still do.  One
day I will write perfect code.  Well... probably not :)

> Steve

C.J.

-- 
moo.