[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH VTPM v3 00/10] Remaining vtpm patches
On 11/19/2012 10:06 AM, Ian Campbell wrote: I was under the assumption that configure.ac was only for building tools, not stubdoms. Still an additional cmake check to configure.ac might not be a bad idea.On Mon, 2012-11-19 at 14:02 +0000, Matthew Fioravante wrote:Another option also would be to remove vtpm-stubdom and vtpmmgrdom from the stubdom install target. This would make them optional components and then cmake becomes an optional dependency.If we were to do this then we'd probably want to add it as an option configure.ac and plumb it through etc. Wecould make it autodetect cmake and build if it can. Actually, even if we don't do this then configure.ac needs to check for cmake as well as updating the README. Especially considering that the TARGET_CPPFLAGS etc.. change whether or not you're on 32 or 64 and also may change if someone changes the stubdom cross compiler setup.From the other mail:Looks like we've grown a dependency on cmake. I vaguely recall discussing before, can you remind me if this is a hard requirement on the end user system or not.Unfortunately it is a hard requirement. Its used to pass the stubdom build flags to the tpm_emulator.This is this line: cd $@/build; cmake .. -DCMAKE_C_COMPILER=${CC} -DCMAKE_C_FLAGS="-std=c99 -DTPM_NO_EXTERN $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -Wno-declaration-after-statement" I took a look and the affect of doing this is not something we can encode in the tpm_emulator.patch Ian. Attachment:
smime.p7s _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |