[xen-tools] Re: More changes

[C.J. Adams-Collier]

On 9/1/07, Steve Kemp <steve at steve.org.uk> wrote:
> On Sat Sep 01, 2007 at 17:44:51 +0000, C.J. Adams-Collier wrote:
>
> > Would you consider re-naming the /tests/ directory to /t/ to match
> > standard CPAN directory layout?
>
>   Sure I'll try to get that done this evening.
>
> > This will mean that checkouts should be made with -P.
>
>   "make update" does this already ..
>
> > I recommend moving to subversion to avoid the complication.
>
>   I'm not interested in subversion; sure it fixes some of
>  the most common warts with CVS development, such as tracking
>  file renames - but if I were to change revision control
>  system I'd rather move to CVS + 2 than CVS+1.

Heh.  Good point.  Subversion is by no means perfect :)

I haven't played much with git, hg or bzr, but they all seem
promising.  Having the backing of the folks from the lkml is likely a
good indication that git is the best of these.

>   (I've been using git for for new projects for a while now,
>   but I've not yet considered migrating *.cvsrepository.org.)

Yes.  Sounds like it would call for a 301, and those can sometimes be
expensive to maintain :)

I merged the code under Xen-Tools-0.1/lib/ with implementation and
unit tests (Xen/Tools.pm and Xen/Tools/Log.pm) into xen-tools this
afternoon, but wasn't able to get 'make test' to run flawlessly.  When
things look clean, I'll submit a diff and a ChangeLog entry.

The main change that you may have issue with, Steve, is that I
re-named 'Makefile' to 'makefile' in order to keep Makefile.PL from
overwriting it.

GNU make prefers 'makefile' to 'Makefile', so functionality won't
change for most use cases.  If the CPAN auto-build tool doesn't
explicitly specify '-f Makefile', I can put a patch in to have it do
so.

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 plan to build a gtk-sharp based virt management
application that makes use of these libraries.  I would prefer to have
Mono P/Invoke into libperl and eval { require Xen::Tools }; rather
than incurring the cost of a system call for each xen management
operation.  Throwing away a perfectly good perl runtime process is
expensive and seems sub-optimal to me.

I could see Python, C/C++, Java, Ruby, etc bindings to this library
using the same mechanism.

libperl FTW and all that :)

Steve, do you mind me mentioning this work in my blog?  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.

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.

With that, I need to put the kiddos to bed :)

Cheers,

C.J.

-- 
moo.