Add a --disable-processor configure arg

When targeting ARM or other systems, it doesn't make a lot of sense to build the
processor library and tools. This patch adds a --disable-processor option to
configure so that configure && make will build only the client library and tests

[mochalatte]

http://breakpad.appspot.com/209001/diff/1/5
File configure (right):

http://breakpad.appspot.com/209001/diff/1/5#newcode3
Line 3: # Generated by GNU Autoconf 2.65 for breakpad 0.1.
ah thanks for getting back to the old version, i'd missed that in a previous
review. makes things simpler if we all just use that for now.

http://breakpad.appspot.com/209001/diff/1/6
File configure.ac (right):

http://breakpad.appspot.com/209001/diff/1/6#newcode88
Line 88: ;;
i think i'm getting lost in the double negatives & autoconf n00bness - does
passing "--disable-processor=yes" mean disable_processor=false in the code and
the processor won't be built?

[Ted Mielczarek]

http://breakpad.appspot.com/209001/diff/1/6
File configure.ac (right):

http://breakpad.appspot.com/209001/diff/1/6#newcode88
Line 88: ;;
On 2010/10/05 18:24:08, mochalatte wrote:
> i think i'm getting lost in the double negatives & autoconf n00bness - does
> passing "--disable-processor=yes" mean disable_processor=false in the code and
> the processor won't be built?  

Autoconf is sort of awful, but if you pass:
--disable-processor then $enableval == no
--enable-processor  then $enableval == yes (the default)

If you pass --disable-processor=yes then it probably doesn't actually disable
the processor code. This is all a side-effect of autoconf using the same code
paths to handle --{enable,disable}-option. See:
http://www.gnu.org/software/hello/manual/autoconf/Package-Options.html
"If no argument is given, it defaults to ‘yes’. --disable-feature is equivalent
to --enable-feature=no."

[mochalatte]

LGTM