Emulator

We have two ways of running Dolphin: with the wxWidgets GUI and with a
command line program. At first, you had to modify a SConscript file to
switch to the non-GUI version, but yesterday I changed the SCons build to
always produce both executables.

Currently the non-GUI executable takes only one argument: the file to
execute (ISO/DOL/ELF). However, I would like to be able to turn on/off
JIT from the command line and also would like to resurrect the "compare
server" feature which would also require new command line options.

To parse command line options, I have considered three options:

1. wxCmdLineParser class from wxWidgets
2. gflags library (suggested by ector on IRC)
3. writing something new

Since this is a standard problem for which solutions exist, I don't think
we should reinvent the wheel. Using wxWidgets would be the easiest thing
to do, but it means the non-GUI executable would still require a GUI
toolkit, which is not a nice dependency. So gflags is currently the first
choice.

gflags is a small BSD-licensed library from Google:
http://google-gflags.googlecode.com/
It does command line parsing, --help output, man page generation and tab
completion support for bash. I had some trouble getting it compiled, but
those problems have now been fixed or worked around.

The main reason for filing this issue is that I'm not sure of the best
way to integrate gflags into the Dolphin build. In any case it would be
put in the "Externals" directory, since that is consistent with how we
treat the other libraries. However, building gflags is not just a matter
of compiling the source files: there are three header files that have to
be configured for the system we are compiling for. I see the following
options with each their pros (+) and cons (-):

1. Let SCons run "configure ; make" of gflags.

• Very little changes to gflags are needed.
• Smallest amount of SConscript code needed.

• Adds dependency on Make and shell tools.
• The "configure" step is slow.
• SCons will not be able to track dependencies, so it would have to
  invoke Make on every build, or we have to resort to ugly/unsafe tricks.

2. Let SCons run "configure" script of gflags and do compilation in
   SCons.

• Very little changes to gflags are needed.
• Small amount of SConscript code needed.

• Adds dependency on shell tools.
• The "configure" step is slow.

• SCons can track dependencies.

3. Let SCons process the ".h.in" files instead of "configure" and do
   compilation in SCons.

• Very little changes to gflags are needed.

• More SConscript code needed.

• No dependency on Make or shell tools.
• The header generation step will be fast.
• SCons can track dependencies.

4. Modify gflags headers to use #defines and typedefs from Dolphin.

• Significant changes to gflags are needed.

• Small amount of SConscript code needed.
• No dependency on Make or shell tools.
• No header generation step.
• SCons can track dependencies.

My current feeling is that option 3 offers the best tradeoff: fast build,
no new tool dependencies, but some effort required to implement and
maintain the header generation step.

Please let me know whether you agree or disagree with this evaluation.
Maybe there is an option I haven't thought of? How will these options
impact the Visual Studio build?