Configure options reorganization #160

• Introduce a new configuration option for assembly optimizations (which in the future will likely not just be for the field implementation), --with-asm=X, instead of it being part of --with-field=X.
• Make --without-asm and --without-bignum work.
• Move the knowledge of which options require what out of build-aux/m4/bitcoin_secp and into configure, leaving the functions there to just be checking for feature availability.
• Improve the summary printed at the end of configure a bit.

@theuni Review please? :)

@sipa Looks generally ok to me. I believe a few of the checks are superfluous though. See patch below.

Also, we'll need to rework the travis build matrix. After this, many of the travis builds will end up being identical even after adding an asm option.

As an alternative: I realize from a coding perspective it doesn't make sense, but from a user's perspective might it make sense to simply the options even further? Something like:

--with-impl=x86_64-asm | 64bit | 32bit | auto
--enable-gmp=true | false

If gmp is enabled, it's used where advantageous. Otherwise, num is disabled and matching options are selected for field/scalar. Do users really need much more control than that?

diff --git a/configure.ac b/configure.ac
index 7d26144..f519b6e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -117,11 +117,9 @@ AC_COMPILE_IFELSE([AC_LANG_SOURCE([[void myfunc() {__builtin_expect(0,0);}]])],
     ])

 if test x"$req_asm" = x"auto"; then
-  if test x"$set_asm" = x; then
-    SECP_64BIT_ASM_CHECK
-    if test x"$has_64bit_asm" = x"yes"; then
-      set_asm=x86_64
-    fi
+  SECP_64BIT_ASM_CHECK
+  if test x"$has_64bit_asm" = x"yes"; then
+    set_asm=x86_64
   fi
   if test x"$set_asm" = x; then
     set_asm=no
@@ -144,10 +142,8 @@ else
 fi

 if test x"$req_field" = x"auto"; then
-  if test x"$set_field" = x; then
-    if test x"set_asm" = x"x86_64"; then
-      set_field=64bit
-    fi
+  if test x"set_asm" = x"x86_64"; then
+    set_field=64bit
   fi

   if test x"$set_field" = x; then
@@ -193,11 +189,9 @@ else
 fi

 if test x"$req_scalar" = x"auto"; then
-  if test x"$set_scalar" = x; then
-    SECP_INT128_CHECK
-    if test x"$has_int128" = x"yes"; then
-      set_scalar=64bit
-    fi
+  SECP_INT128_CHECK
+  if test x"$has_int128" = x"yes"; then
+    set_scalar=64bit
   fi
   if test x"$set_scalar" = x; then
     set_scalar=32bit

@theuni Updated, and fixed travis.

I see what you're saying. I guess the direction this is going in (and you're suggesting to go further in) is not configuring which implementations are used, but which features are available - and have the code figure out what implementations are used. Ultimately that probably means a --with-int128 --with-x86_64-asm and --with-gmp, and not just a single list of implementations and a boolean for GMP. Reason is for example some hypothetical compiler that doesn't have int128, but does have x86_64 assembly (you could use the 64bit field implementation there with asm, but the 64bit scalar implementation wouldn't be available).

An argument against exposing the decisions about implementations to use, is testing: it may become hard or impossible to guarantee all implementations/code paths and useful combinations thereof have been tested.

I think I like keeping the ability to choose different implementations for now, but have the autodetection/selection choose sane defaults.