[libvirt] [PATCH v2] Link libvirt_util with datatypes

[Peter Krempa]

On Wed, Apr 15, 2015 at 16:02:45 +0200, Martin Kletzander wrote:
> On Wed, Apr 15, 2015 at 02:19:04PM +0100, Daniel P. Berrange wrote:
> >On Wed, Apr 15, 2015 at 02:29:52PM +0200, Martin Kletzander wrote:
> >> Most of the types in datatypes.[hc] depend on virObject and virClass,
> >> but they were specified separatedly from that.  We were lucky enough for
> >> this to work because wherever the datatypes files were used, that
> >> file (binary/shared object) was linked to libvirt_util as well.
> >>
> >> Fixing this comes up as a pretty nice cleanup.
> >
> >I'm not really seeing what problem needs fixing here. The libvirt_util
> >library doesn't depend on the datatypes file, and everything that we
> >build links to libvirt_util, so AFAIK there's nothing that needs fixing
> >
> >libvirt_util.la doesn't depend on datatypes.h - at least it shouldn't
> >unless we regressed somewhere.
> >
> 
> Yes, it doesn't, but datatypes depend on libvirt_util.  And since we
> don't have any place in the whole code base where we would use
> libvirt_util and not datatypes, it makes sense to put them together,
> IMHO.  It's just a matter of point of view, but if you want, I can
> make DATATYPES as the library and it would have libvirt_util (or
> virobject, virerror etc. at least) as part of it.  But now we just

I'd rather see this as making datatypes part of the utils library.
libtool should then handle ti just right.

> have DATATYPES_SOURCES variable that has two files inside that don't
> mean anything by themselves alone.  I wanted to fix that because it
> looks cleaner, works and I used to use that when building admin
> library.  I'm not doing that any more, so this is really just a
> clean-up that might help someone else in the future.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150415/d0b4bba0/attachment-0001.sig>