Chandler Carruth 0184a841d3 Begin sketching out the process interface.
The coding style used here is not LLVM's style because this is modeled
after a Boost interface and thus done in the style of a candidate C++
standard library interface. I'll probably end up proposing it as
a standard C++ library if it proves to be reasonably portable and
useful.

This is just the most basic parts of the interface -- getting the
process ID out of it. However, it helps sketch out some of the boiler
plate such as the base class, derived class, shared code, and static
factory function. It also introduces a unittest so that I can
incrementally ensure this stuff works.

However, I've not even compiled this code for Windows yet. I'll try to
fix any Windows fallout from the bots, and if I can't fix it I'll revert
and get someone on Windows to help out. There isn't a lot more that is
mandatory, so soon I'll switch to just stubbing out the Windows side and
get Michael Spencer to help with implementation as he can test it
directly.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171289 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-31 11:17:50 +00:00
..

llvm/lib/Support/Unix README
===========================

This directory provides implementations of the lib/System classes that
are common to two or more variants of UNIX. For example, the directory
structure underneath this directory could look like this:

Unix           - only code that is truly generic to all UNIX platforms
  Posix        - code that is specific to Posix variants of UNIX
  SUS          - code that is specific to the Single Unix Specification
  SysV         - code that is specific to System V variants of UNIX

As a rule, only those directories actually needing to be created should be
created. Also, further subdirectories could be created to reflect versions of
the various standards. For example, under SUS there could be v1, v2, and v3
subdirectories to reflect the three major versions of SUS.