On Tue, Mar 15, 2011 at 08:44:27AM -0500, Anthony Liguori wrote: > On 03/15/2011 07:42 AM, Jes Sorensen wrote: > >On 03/14/11 17:40, Alon Levy wrote: > >>On Mon, Mar 14, 2011 at 04:20:22PM +0100, Jes Sorensen wrote: > >> > >>ok, here is a note where I kinda ignored my own wishes but I want > >>to be very clear on them: > >> libcacard should not be part of qemu. > >> it is here because I once thought it would speed things up. > >> > >>So I'm not taking it out or anything - it's fine with me that it > >>goes into qemu, just as long as it's understood that I'm now maintaining > >>another copy of it for usage outside of qemu, in the spice client (or > >>any other client for that matter - it will be the same when we do vnc > >>support for this). > >Hi Alon, > > > >This bit is somewhat problematic. If QEMU is maintaining a copy of > >libcacard, then that has to comply with the QEMU way of doing things. > >QEMU cannot rely on various portions in the tree behaving in different > >ways. Otherwise it really should be an external library requirement > >pulled in by the build. > > > >I am not sure what is the best way, if it stays in QEMU people will > >eventually start making modifications to it, without looking at the > >other copy that is being maintained. > > Two copies is not really practical. QEMU should be the place that > owns it and things should be consuming a .so from QEMU. >
My bad - I thought you didn't want this. I can do a patch to make qemu build an .so file if configure gets a "--libs", how does that sound? right now that would build just libcacard, I guess libqmp too later? or perhaps have a separate Makefile (Makefile.libs)? Have you given this any thought? > Regards, > > Anthony Liguori > > >Alternatively the external apps that build against it should be taught > >to link with the QEMU version. > > > >Cheers, > >Jes > > > >
