[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:
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.
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.

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

Ian.



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.