search for: libcleanups

...ib \ -I$(top_srcdir)/common/options -I$(top_builddir)/common/options \ @@ -47,6 +48,7 @@ virt_alignment_scan_LDADD = \ $(top_builddir)/common/options/liboptions.la \ $(top_builddir)/common/parallel/libparallel.la \ $(top_builddir)/common/utils/libutils.la \ + $(top_builddir)/common/cleanups/libcleanups.la \ $(top_builddir)/lib/libguestfs.la \ $(LIBXML2_LIBS) \ $(LIBVIRT_LIBS) \ diff --git a/builder/Makefile.am b/builder/Makefile.am index 5f0606ca4..cfe302f9d 100644 --- a/builder/Makefile.am +++ b/builder/Makefile.am @@ -100,6 +100,7 @@ virt_builder_CPPFLAGS = \ -I$(top_srcdir)/gnulib/lib...

...ml2 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 part...

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... -- Pino Toscano

...to 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. > > Thi...

This turned out to be rather more involved than I thought. We have lots of utility functions, spread all over the repository, with not a lot of structure. This moves many of them under common/ and structures them so there are clear dependencies. This doesn't complete the job by any means. Other items I had on my to-do list for this change were: - Split up mllib/common_utils into: -

This is a combination of: https://www.redhat.com/archives/libguestfs/2017-June/msg00046.html [PATCH 00/12] Refactor utility functions. plus: https://www.redhat.com/archives/libguestfs/2017-June/msg00023.html [PATCH v3 00/19] Allow APIs to be implemented in OCaml. with the second patches rebased on top of the utility refactoring, and some other adjustments and extensions. This passes

...hich 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. And the same applies (but a bit less) to gn...

v5: https://www.redhat.com/archives/libguestfs/2017-June/msg00065.html Since v5, this now implements inspection almost completely for Linux and Windows guests. Rich.