[xen-tools] Re: More changes

[C.J. Adams-Collier]

Okay, here's the patch using Build.PL to add a lib/ directory.

I modified bin/xen-create-image to make use of Xen::Tools->log()

No more test are failing now than were failing before :)

Thanks for an alternative that doesn't use Makefile files, Ken.

Cheers,

C.J.

On 9/2/07, C.J. Adams-Collier <cjcollier at gmail.com> wrote:
> 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.
>


-- 
moo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20070903-a.diff
Type: text/x-patch
Size: 96275 bytes
Desc: not available
URL: <http://sym.noone.org/pipermail/xen-tools-discuss/attachments/20070903/0763a7b6/attachment.bin>