On Thu, 2009-10-01 at 09:06 -0300, Klaus Heinrich Kiwi wrote: > On 09/30/2009 10:50 AM, Rajiv Andrade wrote: > >> So I'm defining all AC_ARG_ENABLE() macros the same way for all > >> architectures, and using<root>/usr/lib/pkcs11/Makefile.am choose > >> between building ica_stdll and ica_s390_stdll (btw, it's also my > >> intention to remove ica_stdll and move ica_s390_stll in it's place in > >> the future, since I don't see a reason for two versions) > >> > > I was actually asking about what it implemented and was removed, not > > defending the _code_ itself, I might say additionally that I agree with > > the uniform layout it (the code) is getting. My point is: if configure > > script detects that libica is installed on the machine, the ica token > > compilation must be enabled automatically. It would save us support > > time. Also, the architecture handling isn't a big deal indeed, the > > libica installation would already handled that. > > I see your point. I was thinking that making the user explicitly > enable/disable the tokens at build time would save us support time, but > I also see the value in trying to do things automagically. > > Enabling the tokens when the relevant libraries are found should not be > a huge change to the current code (although my fear is that it won't be > as well organized as of the current patch). My suggestion would be to > add a "summary" screen right after configure is run to summarize which > features are enabled and which aren't. >
That would be awesome, we could invest in automating the tokens build and also make sure that the user will be aware of what was selected. On the pkcscca_migrate, we could make it dlopen() CCA (link dynamically), this way we won't need to make --enable-pkcscca-migrate depend on --with-xcryptolinz, only on --enable-ccatok, making the code cleaner too. However I don't want to make this cleanup patch depend on this, I can do this pkcscca_migrate improvement later. > I'd prefer doing this as a follow-on patch after this huge chunk I sent > you (26 parts!) is committed somewhere (even if it's a experimental > branch), but I can also make the change in the current series (should be > contained to patch 26/26) and re-send. What is your preference? > Sure, given that it will be a development branch, this summary print can be done later too, no need to resend the patchset :-) > > >> > >> I'll send the second revision for this batch and if it's too much for > >> one shot we can discuss splitting them. > >> > >> Thanks for the review, > > I've already got the context, splitting it now wouldn't help that much, > > at least for me. > > Sorry, too late - As you probably noticed, already sent your way this > 26-part patch :( > No, I'm sorry, I sent this email out of sync and too late > We can meet and review the code step-by-step if desirable. > Good, I'll read them first Thanks, Rajiv ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Opencryptoki-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech
