I prefer the first choice, with some caveats.

There is a general design principle for robust scripts that states that there
must a mechanism for avoiding accidental capture of options, so that it is
possible to write scripts that are correct for arbitrary arguments. If "aliases"
is a list of aliases and "make_options" is a list of options to be passed to
make, there must be an algorithm that produces an option string that leads to
the correct interpretation. The usual way to achieve this is by making order
matter and using delimiters like "--" to disambiguate where necessary. (I
suggest to discuss these details offline.)

We would like to have a shortcut for creating and configuring custom builds with
ccmake. This is a bit tricky, because we currently recognize the name of the
build because it is a known alias. So while we could configure a build with
  ./build.py --ccmake unknown_name
we could not build it later with
  ./build.py unknown_name
In the second call, "unknown_name" will be interpreted as an argument for make
of the default config release32.

We could change the behaviour of build.py in the following way: All arguments
that are known aliases are configs (as before) but we also consider all
arguments "foo" as configs if there is a directory "builds/foo". For each alias
config that does not already have a build directory, we create one and call
CMake with the correct parameters. Then we call make for all configs forwarding
all remaining arguments of build.py. The only options that are excluded from
this are the ones we specifically parse (--help, --debug, and --ccmake).

We could alternatively add an option --build, so that
  ./build.py --build unknown_name
would call ccmake if "builds/unknown_name" does not exist and make otherwise. In
this case, I would still allow aliases to be passed without the option, so we
can still write
  ./build.py release32
instead of (or in addition to)
  ./build.py --build release32

What do you think?