Use GNU make for building

[rotty]

This replaces the shell scripts used for building with a GNU make
file. The change also includes slight refactorings of the code, as to
make the protocol selection more flexible.

The main changes, build-system and from a user perspective are:

• Removed the distinction between "combined binary" and per-protocol
  binary. You can now build a multi-protocol binary by setting the make
  variable PROTOCOLS. If you specify only one protocol, you will achieve
  the same effect as using a protocol-specific binary with the old build
  system. By default, all protocols will be built.
• The Debian ifupdown support is now built in, using the command line
  --ifupdown switch. It didn't seem worth it keeping the conditional
  build support for that little code.
• The debian directory is intentionally not included in the source
  tarball. This is recommended to upstreams by Debian to make packing
  easier inside Debian.
• Instead of generating the NaCl and libsodium shim headers, the correct
  set of headers is selected via a preprocessor macro defined by the
  makefile.
• Removed the NaCl auto-build support. Users will have to install either
  NaCl or libsodium themselves. Fetching binaries over http without
  verifying checksums or the like didn't seem such a good idea anyway.

The following code changes were made to facilitate the above:

• Extract parts of common.c into a header file "common.h".
• Create a new file protos.c, containing the list of included protocols
  and a simple by-name lookup function.
• Move run.combined.c to main.c, and eliminate the per-protocol main
  functions. The single-protocol-binary case is subsumed by the slightly
  extended main() residing in main.c.

[rotty]

Note that this is just a basis for discussion, and not yet tested very well. What I'm unsure about is how protocol selection in main() should work. I tried to make the change backward-compatible, but it seems to me that this yields a suboptimal result.

There are further things that could be tweaked building upon this change, if you decide this a valid approach. This is also intended to be the basis for providing "official" Debian packaging, which needs a bit more buildsystem flexibility.

[rotty]

Note that I had a better idea than adding the --ifupdown switch: the ifupdown script starting quicktun can just set the environment variables as the vanilla (non-Debian) quicktun expects them. I'll adapt the change accordingly.

[rotty]

It would also help to know what the original intention of compiling per-protocol binaries was. Is it about binary size, reducing code complexity, and hence attack surface? I could surely adapt this PR to build the single-protocol binaries again, but I I'd like to understand the motivation for them first.

[UCIS]

I do like backwards compatibility. When possible I prefer to put unrelated changes in separate commits.
To comment on your changes:

• Ok to removing the distinction. Perhaps the default protocol selection can be simplified a bit; if there's only one protocol that one should be used (if another PROTOCOL was chosen that could result in an error, or maybe not...). The build could still produce (some) single-protocol binaries.
• Built-in debian configuration support looks OK. I don't like the hard-coded options list in the init bash script (because it would have to be maintained separately) so the built-in solution is preferable.
• Including the debian directory in the source tarball makes it easier to build a local deb package from source. How does excluding it make debian packaging easier? Would renaming the directory help?
• Using preprocessor directives to select the crypto library looks okay (with a common.h file), but should not assume that cryptography is to be included (a raw-only version may be useful for a platform on which building nacl/sodium would be complicated and security is not required)
• It may be possible to include a minimal version of the nacl code (tweetnacl or the _ref versions from nacl, all public domain). Less external dependencies, easier to build.
• protoc.c code could probably be integrated in main.c. I don't think it will be used anywhere else.

I would also like to keep the build.sh script around for now. It could be simplified with some of your changes, and it could live side by side with the makefile.

[rotty]

I do like backwards compatibility. When possible I prefer to put
unrelated changes in separate commits.

OK, I'll try to split the buildsystem PR into multiple commits, and also
try to keep more of an eye on backwards compatibility.

To comment on your changes:

• Ok to removing the distinction. Perhaps the default protocol
  selection can be simplified a bit; if there's only one protocol that
  one should be used (if another PROTOCOL was chosen that could result
  in an error, or maybe not...). The build could still produce (some)
  single-protocol binaries.

OK, I'll try to accomodate this. I think setting PROTOCOL and not having
it available should ideally result in an error, even with a
single-protocol binary.

• Built-in debian configuration support looks OK. I don't like the
  hard-coded options list in the init bash script (because it would have
  to be maintained separately) so the built-in solution is preferable.

I didn't like the hard-coded list much myself, but it seemed preferable
to putting support for a specific network management system into
quicktun itself. It seems like a slippery slope, even though the code to
support ifupdown is quite minimal.

What do you think about having a --list-options switch (or something
alike) that can be used by the ifupdown scripts?

• Including the debian directory in the source tarball makes it easier
  to build a local deb package from source. How does excluding it make
  debian packaging easier? Would renaming the directory help?

See https://wiki.debian.org/UpstreamGuide (section "Pristine Upstream
Source"). The general issue is that for each QuickTun release, there may
be multiple Debian packages, differing in the contents of the debian/
directory (e.g. fixes in the packaging for the same upstream release,
backports, ...).

Renaming the directory would help, indeed. Albeit, I'll revert that
aspect of the change, as this can be done/decided when official Debian
packages are around the corner. (I'm working on this in my spare time,
so I'm not really progressing as fast as I'd like).

• Using preprocessor directives to select the crypto library looks
  okay (with a common.h file), but should not assume that cryptography
  is to be included (a raw-only version may be useful for a platform on
  which building nacl/sodium would be complicated and security is not
  required)

Ah, I didn't think of that. I'll add the possibility of "CRYPTLIB =
none", in which case only the "raw" protocol will be built.

• It may be possible to include a minimal version of the nacl code
  (tweetnacl or the _ref versions from nacl, all public domain). Less
  external dependencies, easier to build.

I'd recommend not doing that, for the reasons also mentioned in the
Debian upstream guide. It really depends on which target userbase you
have in mind compiling quicktun. I think all the BSDs and Linux should
have libsodium and/or NaCl easily available.

• protoc.c code could probably be integrated in main.c. I don't think
  it will be used anywhere else.

Makes sense.

I would also like to keep the build.sh script around for now. It could
be simplified with some of your changes, and it could live side by
side with the makefile.

I'm OK with that, but it means an added maintainance burden, if
buildsystem changes are to be made. I think GNU make as a build dependency
is even more readily available than libsodium/NaCL.

[rotty]

I'll close this PR now, it will be superseded by a series of more self-contained, PRs.