On Thu, Jun 17, 2010 at 3:31 PM, Daniel P. Berrange <berrange(a)redhat.com> wrote:
On Thu, Jun 17, 2010 at 02:20:01PM +0200, Andrew Beekhof wrote:
> On Wed, Jun 16, 2010 at 2:24 PM, Darryl L. Pierce <dpierce(a)redhat.com> wrote:
> > On Tue, Jun 15, 2010 at 10:51:50PM -0500, Ryan O'Hara wrote:
> >> On Tue, Jun 15, 2010 at 02:36:44PM -0400, Darryl L. Pierce wrote:
> >> > The build environment now only requires a new user to:
> >> >
> >> > 1. clone the git repository
> >> > 2. ./bootstrap
> >> > 3. ./configure, and install any requirements
> >> > 4. make
> >>
> >> This seems very odd to me. We need a bootstrap script to build the
> >> source? It also requires git, which also seems odd.
> >
> > Our development environment requires git, so this isn't a new
> > dependency.
> >
> >> I'd prefer that we limit ourselves to the following steps:
> >>
> >> 1. ./autogen.sh
> >> 2. ./configure
> >> 3. make
> >> 4. make install
> >
> > Our development is no more complex with gnulib, it just replaces
> > ./autogen.sh with ./bootstrap to setup our environment, since it will
> > pull gnulib down for you if you don't have it installed.
> >
> > This is the same development environment used by libvirt and other
> > projects that need to be cross-platform.
>
> Does cross-platform include windows?
Yes, the Windows support is likely the biggest benefit of using
GNULIB in a project. It even manages to unfsck the Win32 sockets
API so that you can use normal file handles instead of Windows
HANDLES, thus making normal APIs like poll() work on Win32 sockets
again. The other very notable thing is that it provides a working
printf() impl for Win32, ie one that can actually print int64
data types without totally mangling the output.
That sounds like a worthwhile benefit.
> Because I've never encountered anything truly interesting that
> required gnulib and pacemaker compiles on all the linuxs, BSDs, even
> OSX.
There are many many apps & libraries using GNULIB that you use
on your system everyday. coreutils, gnutls, gpg, gzip, parted,
sed, tar and many more:
http://git.savannah.gnu.org/cgit/gnulib.git/tree/users.txt
Oh no doubt many projects use it and get value out of it.
I'm just saying I've never seen anything in the cluster stack (which
is quite a bit of C code across a number of projects) that
necessitated it - but then I've never needed to support windows
either.
What I really don't like how it makes hg/git tarballs unusable without
secondary downloads - problematic for rpm builds.
And "make dist" doesn't make me any happier... why would I want to
host additional tarballs when every possible version can be obtained
directly from the scm?
So I guess I'm saying that its far from a slam dunk and if we're going
to use it, I'd like there to be a pretty compelling reason.
From what you're saying though, "windows" sounds like a
pretty good reason.
For creating portable C code there is only really a choice of
- Using POSIX APIs and writing your own portability fixes
Never had to write any. Sorry.
- Using POSIX APIs + GNULIB
- Using a portability libray (glib, apache apr, mozilla nspr)
The first way is madness because you'd be reinventing stuff that
has already been written in GNULIB and its almost guaranteed that
custom portability code will be worse, because it won't have the
same wide testing that gnulib enjoys.
Choosing a portability library like glib, apr or nspr is certainly
a valid choice. If not chosen though, gnulib really is the best
way to go. It isn't going to magically solve all your platform
portability problems, but it is going to get your very far along
compared to coding portability wrappers by hand. Adding GNULIB
to libvirt to deal with portability was one of the best decisions
we've made for code maintenance
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|