Libguestfs - Jun 2017 - Re: [PATCH v6 05/41] utils: Split out cleanups into common/cleanups.

On Friday, 16 June 2017 16:58:53 CEST Richard W.M. Jones
wrote:
> On Fri, Jun 16, 2017 at 03:24:55PM +0200, Pino Toscano wrote:
> > On Thursday, 15 June 2017 19:05:55 CEST Richard W.M. Jones wrote:
> > > Those cleanups which only depend on libc, gnulib or libxml2 are
split
> > > out into a separate common/cleanups directory.
> > > ---
> > 
> > IMHO a single cleanups.c source should be enough, otherwise it's
overly
> > split...
> 
> I think you do need to split it.  The reason is that if the program
> uses libcleanups.la but doesn't link to (eg) libxml2 then the link
> will fail.  We could either force everything to link unnecessarily to
> libxml2 or we can split the object files so that the libxml2
> dependency is never pulled in if the main program doesn't use it.
This is for the libxml2 parts though. Also, I see that the cleanups are
split from libutils, but then
a) libcleanups is basically used where libutils is
b) patch #14 makes the daemon link both libcleanup and libutils
so IMHO the libc + gnulib cleanups could simply stay where they are,
in libutils
> And the same applies (but a bit less) to gnulib.  I'm not sure
> anything doesn't link to gnulib though, and probably everything should
> (except examples but they don't use cleanups).
I think it's basically used everywhere, even more so after the switch
to getprogname (which makes gnulib needed on Linux).

-- 
Pino Toscano

On Mon, Jun 19, 2017 at 10:25:33AM +0200, Pino Toscano
wrote:
> On Friday, 16 June 2017 16:58:53 CEST Richard W.M. Jones wrote:
> > On Fri, Jun 16, 2017 at 03:24:55PM +0200, Pino Toscano wrote:
> > > On Thursday, 15 June 2017 19:05:55 CEST Richard W.M. Jones wrote:
> > > > Those cleanups which only depend on libc, gnulib or libxml2
are split
> > > > out into a separate common/cleanups directory.
> > > > ---
> > > 
> > > IMHO a single cleanups.c source should be enough, otherwise
it's overly
> > > split...
> > 
> > I think you do need to split it.  The reason is that if the program
> > uses libcleanups.la but doesn't link to (eg) libxml2 then the link
> > will fail.  We could either force everything to link unnecessarily to
> > libxml2 or we can split the object files so that the libxml2
> > dependency is never pulled in if the main program doesn't use it.
> 
> This is for the libxml2 parts though. Also, I see that the cleanups are
> split from libutils, but then
> a) libcleanups is basically used where libutils is
> b) patch #14 makes the daemon link both libcleanup and libutils
> so IMHO the libc + gnulib cleanups could simply stay where they are,
> in libutils
OK, I'll combine gnulib cleanups back into libc cleanups.

Also I checked and you are correct that everywhere which uses
common/cleanups also uses common/utils, so I'll put cleanups back
into utils.

Rich.
> > And the same applies (but a bit less) to gnulib.  I'm not sure
> > anything doesn't link to gnulib though, and probably everything
should
> > (except examples but they don't use cleanups).
> 
> I think it's basically used everywhere, even more so after the switch
> to getprogname (which makes gnulib needed on Linux).
> 
> -- 
> Pino Toscano

> _______________________________________________
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

On Mon, Jun 19, 2017 at 11:59:11AM +0100, Richard W.M. Jones
wrote:
> On Mon, Jun 19, 2017 at 10:25:33AM +0200, Pino Toscano wrote:
> > On Friday, 16 June 2017 16:58:53 CEST Richard W.M. Jones wrote:
> > > On Fri, Jun 16, 2017 at 03:24:55PM +0200, Pino Toscano wrote:
> > > > On Thursday, 15 June 2017 19:05:55 CEST Richard W.M. Jones
wrote:
> > > > > Those cleanups which only depend on libc, gnulib or
libxml2 are split
> > > > > out into a separate common/cleanups directory.
> > > > > ---
> > > > 
> > > > IMHO a single cleanups.c source should be enough, otherwise
it's overly
> > > > split...
> > > 
> > > I think you do need to split it.  The reason is that if the
program
> > > uses libcleanups.la but doesn't link to (eg) libxml2 then the
link
> > > will fail.  We could either force everything to link
unnecessarily to
> > > libxml2 or we can split the object files so that the libxml2
> > > dependency is never pulled in if the main program doesn't use
it.
> > 
> > This is for the libxml2 parts though. Also, I see that the cleanups
are
> > split from libutils, but then
> > a) libcleanups is basically used where libutils is
> > b) patch #14 makes the daemon link both libcleanup and libutils
> > so IMHO the libc + gnulib cleanups could simply stay where they are,
> > in libutils
> 
> OK, I'll combine gnulib cleanups back into libc cleanups.
I had to split gnulib cleanups out again into a separate object file.

There are some OCaml bytecode binaries that we build for testing where
it is difficult to statically link with -lgnu (and not necessary either).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html