One more silent error. ax_pthreads will fail on -Werror, so we still
need to fix that.

Since we removed `move` from the dma API, bindings are now useless.

Use m4 to define autoconf-level version variables, following the naming
scheme of semver.org

To make use of these variables in the headers and sources, a
generated-header is added in aml/utils/version.h

Also add a simple test for that part of the lib.

While the current bitmask management is heavily inspired by libnuma, it is not
as easy to use has the libnuma API. This patch is an attempt to refactor
to code towards something cleaner.

- create one directory per building block in src and include
- keep one directory for tests, \
  otherwise automake make them "test suites"
- move to AC_OPENMP, which is from autoconf 2.62 (2008)

Force libtool to static link the PIC version of our jemalloc import into
libaml, making libaml standalone. This requires us to test some
additional libraries in our own configure (pthread, and dlopen).

This also solves the long-standing issue of `make check` only working after
`make install`, while removing our custom jemalloc from the installed
libraries.

Fixes #26.

Mbind is giving us trouble again, will need to spend time looking at it
carefully.

Instead of asking the user to provide the offsets into a tiling, add a
function providing a tileid. This tileid corresponds to the in-memory
order of tiles, making the tilestart functions a lot simpler.

We still need to split the tileid for tilestart because scratchpads
create requests based on tileids.

Also add a unit test for tiling_2d, to make sure we're not doing
anything crazy.

We are starting to work on benchmarks to evaluate the usefulness of this
library. Instead of integrating them into the testing infrastructure, it
makes more sense for them to have their own directory and a different
way of handling them.

This patch:
 - creates a benchmark directory for actual codes that we want to use as
   benchmarks of our library.
 - moves functional tests into it.
 - add proper OpenMP detection for these codes

This is a second type of use for the scratchpad: a single master
thread is responsible for launching all data movements, but the tiles
are worked on in parallel. We support this model by using a sequential
scratch on top of a parallel dma.

Add openmp version of the previous functional test. We also rename them,
to mark the fact that those two tests are designed to use a *single-thread*
to run the kernel across an entire tile.

This patch reintroduce the first functional test, a stream add
implementation using pthreads for parallelism. We make use of our
scratch_par implementation to implement a pipelined version of the
application, where each worker thread is using its own batch of tiles,
and migrating data asynchronously.

Add a scratchpad that creates one pthread per request, to call
synchronous dma operations.

The intent is to end up with a cross product of programming language
support between dma and scratch:
- scratch_par + dma_seq gives users parallel scratch requests
- scratch_seq + dma_par gives users sequential access to parallel moves

The two other options don't make as much sense though.

Add a generic vector type to the library, with some special features:
- the elements are embedded in the vector, and not pointers
- each element must include an int field that is used as a "key"
- the element has a "null" value for its key, used to indicate that this
element of the vector is null.
- add/remove functions provide access to a new element/free it from the
vector, but don't "destroy" it.
- resize on add is exponential.

This patch includes implementation and unit test.

This is the initial implementation and validation of a scratchpad: a
logic unit that handles tracking data across a "main" area and a
"scratch" area.

The API and internals will probably change again soon, as there's no
clear way to implement a move based scratchpad on this one.

Note that this implementation doesn't do any tracking, not really, and
that's the next step.

Add working implementation of copy and move to dma_linux_par, and
corresponding unit test.

This patch adds the basics for a dma interface, including
type-dependent requests structures, and an API based on explicit
copy/move calls.

The APIs is flexible enough to deal with sync/async calls. The internal
design is inspired by aml_area, with the goal that create/init stay type
specific, but the core interactions are generic.

Implement 1d tiling and simple binding support. The idea is to allow
an application to explain the AML how data should be organized, and to
be able to reuse this info when dealing with memory movement.

The current interfaces are not great, but they work.

Using both --with-jemalloc-prefix=jemk_ and --with-install-suffix=-aml
ensures that the libjemalloc we build for our internal use has unique
functions names and library names.

This patch fixes a problem with the libtool configuration, where we had
to link a static jemalloc library into the shared aml library to make
everything work. Instead, we can now use the proper LIBADD variables
with the unique library.

Note that with this patch the `make check` target requires a `make
install` beforehand.

This is the result of countless interations on the internal design of
the various building blocks we want to have for this library.

At this point, I hope that this is stable enough. There are still some
tweaks needed here and there, but the core is implemented AND tested.

Some of the design decisions made:
- all functions are public, but most are not meant to be used directly.
- intended public functions take "generic" structs as arguments
- intended actual implementations rely on more complex structures, with
their own family of data and operators.
- split all objects between data and operator structs.

Exemple:
- area.c and arena.c are generic dispatch functions to call the actual,
  specific implementations.
- struct aml_area and struct_aml_arena are the same.

Currently implement:
- 2 area types: posix (malloc) and linux (numa).
- 1 arena type: jemalloc

This is a redesign of the library, as a hierarchy of core objects
implementing its various features. The idea is to create an API that is
as flexible and customizable as possible, by exposing as much as
possible of its internals, so that users can create customs versions
easily.

We also move away from memkind as a possible backend, opting instead to
vendor the jemalloc interface and implement everything ourselves on top
of that.

We expect to start building the low-level pieces using hwloc as a
backend soon, at least in terms of accessing available devices.

This is a rewrite of the existing code into a memory library exposing
more of its internal abstractions. This refactoring is required to:
- make progress faster by focusing on the core new features
- abstract more of the underlying components and expose those
abstractions
- build upon existing libraries (memkind) for the internal stuff.

Memkind is used as a crutch here, we do not intend to use it in the long
term, as some of its internal are opposed to what we want (topology
management in particular).

Nevertheless, it currently provides a good allocator internally, and
decent access to deep memory, for now.

Over time, we figured out that the best way to build this API was to
create several layers of APIs, each with more abstractions over the
devices. At the same time, we want each layer to expose its internal
mechanisms, so that a user can customize any of them.

This is why we end up with areas and dma engines, and we will add in the
future other stuff, like data decomposition and distribution methods, as
well as direct support for "pipelining".

This is a mmap-based, non-transparent version of the library, with a
unit test checking that we can call move_pages properly from it.

No node tracking performed. Memcpy not working.

This is the first working version of the library. It does very little:
- only numa support
- one allocation per node only
- limited tests
- limited set of functions

Nevertheless, this gives a good idea of what the API should look like, and the
kind of benchmarks we can write with it.