Re: [Xen-devel] [PATCH VTPM v3 00/10] Remaining vtpm patches

[Matthew Fioravante <matthew.fioravante@xxxxxxxxxx>]

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