[doc] Some rewording

This commit is contained in:
Matteo Cypriani 2016-11-02 23:58:37 -04:00
parent 8053876588
commit a567782557
2 changed files with 26 additions and 23 deletions

View File

@ -24,13 +24,14 @@ above should also work. Compilation of the C modules has been tested
with GCC and Clang and should work with older versions of these
compilers.
The additional tools are also recommended:
The following additional tools are recommended:
- ``perl``
- ``pod2man`` (normally provided in the same package as //Perl//)
- ``doxygen``
- ``txt2tags``
If you miss one or more of the requirements, the concerned modules will
If you're missing one or more of the requirements, all the modules will
not be built.
OwlPS uses //CMake// as a build manager. You need to install it (package
@ -40,12 +41,11 @@ it is not shipped with the main CMake package (package
``cmake-curses-gui`` on Debian).
It is strongly advised to build out of the source tree, which can be
achieved by typing for instance (assuming OwlPS' source files are in
``~/owlps``):
achieved by typing the following commands from the source tree:
```
mkdir ~/owlps/build
cd ~/owlps/build
mkdir build
cd build
cmake ..
```
@ -130,7 +130,7 @@ OwlPS Client, just type ``make owlps-client.static``. If you want to
generate static executables for all the modules, call the ``static``
meta-target (``make static``).
So called “semistatic” targets are also provided. The semistatic
So-called “semistatic” targets are also provided. The semistatic
executables are statically linked to OwlPS libraries (such as libowlps),
but dynamically linked to other libraries. This allows for quick testing
of libraries changes as well as running on systems where you can install
@ -152,7 +152,7 @@ To run the unit tests, use the ``test`` target:
``` make test
Currently, only OwlPS Positioner has unit tests.
Currently, only OwlPS Positioner has (partial) unit tests.
= Compiling for OpenWrt =

View File

@ -23,12 +23,12 @@ June 2013
+ What is OwlPS? +
**OwlPS** (//Owl Positioning System//) is a positioning (localization)
system based on the IEEE 802.11 radio network (Wi-Fi). It targets mainly
UNIX-like operating systems and is developed and tested primarily on
GNU/Linux, but it should work on BSD platforms as well. Originally
developed at the University of Franche-Comté (Université de
Franche-Comté, France), it is released under the terms of the CeCILL
free software license (GNU GPL-compatible).
system based on the IEEE 802.11 radio network (Wi-Fi), targeting mainly
indoor environments. It is developed and tested primarily on GNU/Linux,
but it should work on BSD platforms as well. Originally developed at the
University of Franche-Comté (Université de Franche-Comté, France), it is
released under the terms of the CeCILL free software license (GNU
GPL-compatible).
OwlPS uses an infrastructure-centred architecture, which means the
infrastructure does the measurements and computes the mobile terminals'
@ -64,10 +64,12 @@ If you would like to contribute to OwlPS, you can:
- use it, test it, and report suggestions and bugs on the forge:
http://code.lm7.fr/p/owlps/issues/
- get the last development code, add functionalities and send me pull
requests by email or submit code reviews on the forge:
- get the latest development code, add functionalities and send me pull
requests by email or on the forge:
http://code.lm7.fr/p/owlps/review/
You can get improvement ideas from the ``TODO.t2t`` file.
@ -76,8 +78,8 @@ If you would like to contribute to OwlPS, you can:
++ Timeline ++
There is no precise timeline for OwlPS, but the file TODO.t2t lists a
bunch of things that should be addressed at some point. A development
There is no precise timeline for OwlPS, but the file ``TODO.t2t`` lists
a bunch of things that should be addressed at some point. A development
point release is made after some work has been done, usually mainly on a
particular topic. Usually such a release represents between 30 and 90
commits.
@ -114,11 +116,12 @@ revision number is not mandatory, but it is allowed. For example:
The communication protocol between the elements of the system is
guaranteed to stay the same across revisions of a given stable branch
(e.g. mixing modules of versions 1.2, 1.2.1 and 1.2.2 is possible). In
development branches, the protocol can evolve from one point release to
the next (e.g. mixing modules of versions 1.3.0 and 1.3.1 is not
possible). Changes in communication protocols, libraries' APIs, file
formats, etc., are pointed out in the ``CHANGELOG`` file.
(e.g. mixing modules of versions 1.2, 1.2.1 and 1.2.2 would be
possible). In development branches, the protocol can evolve from one
point release to the next (e.g. mixing modules of versions 1.3.0 and
1.3.1 may not be possible). Changes in communication protocols,
libraries' APIs, file formats, etc., are documented in the ``CHANGELOG``
file.