1. Design notes

The porting layer design adheres to concepts of APR (Apache Portable Runtime libraries). These particularly include: Detailed APIs mainly follow APR standard, but there may not be strict correspondence in signatures. Pure C should be used for implementation.

Using APR binaries directly

We define our own headers (aligned with APR), but do not wrap APR functions in code (no delegating calls). Instead, we map our signatures to APR functions directly, where it is possible, - via a set of defines, like this:
#define port_allocator_create(allocator) apr_allocator_create(allocator)
#define port_allocator_destroy(allocator) apr_allocator_destroy(allocator)
So, there is no runtime performance penalty at all.

Why don't we use APR headers directly? Because, current approach has several advantages which we consider significant:

Of course, we also realize drawbacks of it:

2. Directory structure

Porting functionality is split to several groups (atomics, file I/O, mempools, etc). Each group has a base directory, which contains subdirectories with actual code. These subdirectories are named after the platforms and/or architectures they are compiled on. If there is a strong dependency on both OS and machine architecture, the subdirectory name should combine both. For example:
   Port
	|
	 -> file_io
	|	|
	|	 -> linux
	|	|
	|	 -> windows
	|
	 -> atomics
		|
		 -> linux_em64t
		|
		 -> linux_ia32
		|
		 -> windows
Public headers are kept in a separate base directory named include. Implementation headers may be kept in source directories?

3. Build system

Currently we reuse VM build system based on MakeCommon.
TODO - document platform defines and macros.

4. APR issues