sgpemv2/doc/sgpem2dman.texi

840 lines
25 KiB
Plaintext

\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename sgpem2dman.info
@settitle SGPEMv2 Developer Manual
@include vers-dman.texi
@c %**end of header
@dircategory SGPEM v2 - A Process Scheduling Simulator
@direntry
* Developers: (sgpem2dman)Top
@end direntry
@c % --------------------------------------------------
@copying
This is SGPEMv2 Developer Manual (version @value{VERSION},
@value{UPDATED}).
Copyright @copyright{} 2005 University of Padova, dept. of Pure
and Applied Mathematics
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
@end copying
@c % --------------------------------------------------
@titlepage
@title SGPEMv2 Developer Manual
@subtitle for version @value{VERSION}, @value{UPDATED}
@author Giovanni Giacobbi (@email{ggiacobb@@studenti.math.unipd.it})
@author Filippo Paparella (@email{ironpipp@@gmail.com})
@author Paolo Santi (@email{psanti@@studenti.math.unipd.it})
@author Matteo Settenvini (@email{matteo@@member.fsf.org})
@author Marco Trevisan (@email{evenjn@@gmail.com})
@author Djina Verbanac (@email{betalgez@@yahoo.com})
@author Luca Vezzaro (@email{lvezzaro@@studenti.math.unipd.it})
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
@c Output the table of contents at the beginning.
@contents
@c % --------------------------------------------------
@c SGPEM v2 Developer Manual
@c % --------------------------------------------------
@ifnottex
@node Top, History, (none), (dir)
@top How to contribute to development
@insertcopying
@end ifnottex
@menu
* History:: The history of changes to this document.
* Directory overview:: How SGPEM sources are organized
* Coding style:: Here there are the rules you should abid
to when working on SGPEM
* Committing changes:: Some notes on how we keep our
versions organized, how to use
our repository, and how we would
like you to commit patches
* License:: The full text of the license under which this
manual is given to you
* Concept index:: Complete index
@end menu
@c % --------------------------------------------------
@node History, Directory overview, Top, Top
@unnumbered History
@table @strong
@item 2005, December 26th, @r{--- Matteo Settenvini}
Changed directory layout for @samp{src}. Added
@samp{swe/prototypes} to repository layout.
Added one more convention about C++ header files and their
licensing.
@item 2005, December 11th @r{--- Matteo Settenvini}
Added sources' directory description and repository usage
guidelines. Included full FDL license text.
@item 2005, November 8th @r{--- Matteo Settenvini}
First draft of this document
@end table
@c % --------------------------------------------------
@node Directory overview, Coding style, History, Top
@chapter Directory overview
@cindex directory layout
If you need to work on SGPEM sources, you'll probably
be interested in understanding how this package directory
structure is organized.
What follows is the tree you'll find after uncompressing
the SGPEM tar archive.
@table @samp
@item config/
Files used by Autotools while configuring
and compiling SGPEM.
@item data/
Various data SGPEM will use at runtime, like icons,
images, XML DTDs, User Interface (@file{*.ui})
definition files, and so on.
@item doc/
Inside this directory you'll find the User and Developer
Manuals, like the one you're reading, ready to be compiled.
@item desktop/
The desktop menu entries for FreeDesktop compliant
Desktop Environments.
@item distro/
Files used to prepare a package for a specific platform,
maybe containing the installer data.
@item m4/
M4 macros used by Autoconf.
@item po/
Here are stored the Gettext PO catalogs. If you are a
translator, you should first look here in order to
localize SGPEM into your language.
@item src/
The source files of SGPEM.
@end table
@c % --------------------------------------------------
@node Coding style, Committing changes, Directory overview, Top
@chapter Coding style
@cindex coding style
In this chapter we explore some self-imposed coding standards
we tried to follow when coding SGPEM.
If you plan to extend it in any way, you should abid to the
guidelines explained thereafter.
@menu
* Editors :: Some things you should know about indentation
and editors
* Coding in C++::
@end menu
@c % --------------------------------------------------
@node Editors, Coding in C++, Coding style, Coding style
@section Editors
@cindex editors
@cindex emacs
@c this needs rework, of course
IDEs are a bad choice, since usually they leave your directory
dirty, and full of temporary or project files. Please avoid their
use if not strictly necessary.
A good choice for an editor is @acronym{GNU}
Emacs, but every other editor that both insert spaces instead of
tabulation characters and has a good Unicode support will do.
Your files should be in ``UNIX mode''; that is, only a char is used
for a newline. On DOS-based systems, usually two chars are employed:
the newline char and the carriage return one.
Failure to check your text files are correctly saved wastes space
and others' patience, so please take care.
This command usually fixes the problem (@emph{note}: run it as
it is only if no binary files are present in the current directory!):
@example
for i in *; do tr -d '\r' < $i > $i.d; mv $i@{.d,@}; done
@end example
``Emacs-style'' indentation is useful to ensure that your file will
be correctly indented if another developer on another machine
opens it with Emacs, Vim, Notepad, or what else he likes. A good
idea is to use an editor which substitutes the @key{TAB} character
with spaces. Most UNIX editors indent text files cleverly.
@acronym{GNU} Emacs has another nice property: it can automatically indent
code in a whole region for you, with @kbd{M-x indent-region}.
Moreover, if you can get accustomed to it, you can activate the
automatic indentation while in a programming mode, by
typing @kbd{C-c C-a}.
Experienced programmers find it saves quite a lot of time, but
we guess it's just a matter of taste.
@c % --------------------------------------------------
@node Coding in C++, (none), Editors, Coding style
@section Coding in C++
@cindex c++
@cindex coding, style
SGPEM is mostly written in C++, an Object Oriented language
ideated by Bjarne Stroustrup and standardized in 1998 by ISO.
Here are explained some guidelines you should keep well in mind
if you want to contribute to this project.
@menu
* C++ Coding Style::
* C++ Coding Conventions::
@end menu
@c % --------------------------------------------------
@node C++ Coding Style, C++ Coding Conventions, Coding in C++, Coding in C++
@subsection C++ Coding Style
@cindex coding style
These are some notes on coding style, and things
you should keep in mind whenever extending SGPEM
source code.
Patches to the source that don't uniform to these
guidelines are likely to be rejected and need rework.
Coding styles are highly subjective and are often the
cause of harsh holy wars. Here we try also to give
a rationale of these choices, supporting our statements.
@enumerate
@item
Left curly braces go on a newline, respect to
the statement that comes before them. Right curly
braces are to be put into a newline too.
It may make you feel uneasy at first, but this
behaviour is preferable because it clearly let you
identify code blocks.
Moreover, it is observed that putting left curly
braces on the same line of a statement isn't a rule
you always follow: a lot of exceptions are raised by
particular situations, like: ``should my brace go on the
same line after a class initialization list? and after
a @code{for} loop declaration? what happens after
namespaces declaration?''
So it's best to stick to a well known practice and
put it always on a newline.
A lot of complex software projects follow this rule
because it also increases manutenibility: keep in mind
that you aren't writing code for yourself, but for others
to read.
@item
The return type for every function goes on a
line, while the function name and its parameters
go on the following, without any leading space.
This makes easier to @command{grep}
the source. For example, if you're searching for a
declaration of @code{int foo::bar()} inside a large
directory, grepping for: @samp{'/^foo::bar/g'} will
immediately pop out the correct result, whereas,
if you didn't follow this rule, you would have
searched for @samp{'/foo::bar/g'}, thus finding
@strong{all} recurrences of the function in the code,
even function calls.
@item
Use the following example to understand how we want
you to space expressions:
@example
@code{ type var = exp1 OP (exp2 OP fun1(exp3)); }
@end example
And for parameters, the following spacing is preferable:
@example
@code{ function(par1, par2 = value, ...)}
@end example
@item
Please define pointers like @code{type* var}
instead of @code{type *var}.
@item
Labels go indented on the same level of the
containing code block. For example:
@example
@verbatim
switch(x) {
case 1:
// foo
case 2:
// bar
default:
// baz
}
@end verbatim
@end example
Remember that also @code{public}, @code{protected} and
@code{private} are labels.
@item
Put incomplete class declarations before their interface,
documenting it. For example:
@example
@verbatim
//! I'm a useless class
/** This class is completely useless. */
class C;
// [...]
class C {
public:
// [...]
};
@end verbatim
@end example
@item
All header files of the libs and the engine
follow a common model. Try to adhere to it
by looking at existing headers. Document them
fully, even if it is tedious, using a
Doxygen-like syntax. The payback will be
high, I assure you.
@item
Class names are composed of UpperCamelCase words.
Member functions are composed of
lowercase words @strong{except}, separated by
an underscore, since both the STL and Gtk-- use
this convention.
Member data are lowercase words (can be
separated by an underscore).
Enums members are lowercase and they have
a prefix that tells something about their
function, e.g., in an enum named @emph{signal},
``@code{signal_*;}''.
Macro names are written all in capital.
@item
Private member object and function names always
begin with an underscore. Public and protected
ones don't.
@item
Some (broken?) versions of autotools had problems with extensions
other than @samp{.cc} for C++ implementation files (e.g.
automake didn't produce correct implicit rules for them).
Consequently, in order to avoid problems, we require you
to use the following extensions:
@itemize
@item
@samp{.cc} : C++ implementation files
@item
@samp{.hh} : C++ header files
@item
@samp{.tcc} : Template implementation files
@end itemize
You can also add to the end of your @file{~/.emacs} the line:
@example
@code{(add-to-list 'auto-mode-alist (cons "\\.tcc\\'" 'c++-mode))}
@end example
to automatically associate the @samp{.tcc} extension to
the @samp{c++-mode}.
@end enumerate
@c % --------------------------------------------------
@node C++ Coding Conventions, (none), C++ Coding Style, Coding in C++
@subsection C++ Coding Conventions
@cindex coding conventions
Some common rules you should keep in mind when writing
new code:
@enumerate
@item
Never use @code{std::cout/cerr} if you can do
without them.
Use @code{printf()} and @code{fprintf()} from
@code{cstdio} instead,so that marking strings
for @command{gettext} translation will be easier.
@item
Don't use ``@code{using}'' directives into the
global space, even in a @samp{.cc}, and neither in other
namespaces. If you don't keep this in mind,
you're buying to everybody a (big) problem.
``@code{using}'' makes sense
at the beginning of a function to improve
code readability, and you should be specific:
@enumerate
@item
``@code{using namespace std;}'' is bad
@item
``@code{using std::string;}'' is good
@end enumerate
@item
When treating long template names, remember that
@code{typedef} (along with @code{typename} as
needed) are your best friends, expecially at
the beginning of class declarations or function
definitions.
@item
``@emph{Syscalls}'' are evil for portability.
Thread calls can sometimes escape this rule (since
they're quite different from system to system,
and @acronym{GNU}/Linux
ones are really good), but
remember that every UNIX/Win32/Solaris/etc.
native call you use means extra-work somewhere
in the near future.
If a portable toolkit we're using provides the
same functionality, it should be preferred to a
system call.
@item
You should start all your source files, both header
and implementation ones, with a license notice, like
this (no leading white lines):
@smallexample
@group
// path/from/topsrcdir/file.ext - Copyright @strong{<year>}, University
// of Padova, dept. of Pure and Applied
// Mathematics
//
// This file is part of SGPEMv2.
//
// This is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// SGPEMv2 is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with SGPEMv2; if not, write to the Free Software
// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
@end group
@end smallexample
The style you use to comment this out obviously changes with
the language you're employing.
@item
Only exportable classes and functions inside
a library should be marked with correct
visibility attribute (usually a macro we defined
as @code{DLL_EXPORT}). All the others are marked with
@option{--visibility=hidden} from the compiler, and aren't
available outside the @acronym{DSO, Dynamic Shared Object}
they live in, so that they don't clutter
the @acronym{DSO} namespace.
@item
When you do something, remember to update the
@emph{ChangeLog}. This is essential.
More on this on @ref{Committing changes}.
@item
Remember macros for inclusion at the beginning of header
files, as well in template implementation files.
In the latter case, you may want to include the template
implementation files in the corresponding header files.
An example of a correct inclusion directive is:
@example
@verbatim
#ifndef HELLO_WORLD_HH
#define HELLO_WORLD_HH 1
// interface definitions
#endif
@end verbatim
@end example
@item
Please follow this order when declaring a class interface:
@enumerate
@item
Incomplete declarations of nested classes and
friend functions / classes declarations.
@item
Typedefs
@item
Enums
@item
Non-static member functions
@item
Static member functions
@item
Static constant data members
@item
Variable data members
@end enumerate
Static non-const data members shouldn't exist.
Nested classes go declared @strong{outside} their
containing class. For example:
@example
@verbatim
class C;
class C {
class D;
// ...
};
class C::D {
// ...
};
@end verbatim
@end example
The order for visibility should be: @code{public}, then
@code{protected}, then @code{private}.
@end enumerate
@c % --------------------------------------------------
@node Committing changes, License, Coding style, Top
@chapter Committing changes
@cindex repository
@cindex subversion
SGPEM sources are held in a repository managed by
Subversion. This is not an introduction on how to
use this tool. For that, you should refer to its own
manual, located at @url{http://svnbook.red-bean.com/}.
Rather, it sets some ``best practices'' you ought
to follow committing changes to the repository.
@menu
* Introduction and goals::
* Repository layout::
* Basic svn usage::
* Gold rules on committing::
* How to write good log messages::
* Conflicts resolution::
@end menu
@c % --------------------------------------------------
@node Introduction and goals, Repository layout, Committing changes, Committing changes
@section Introduction and goals
@cindex repository
@cindex subversion
The Subversion repository, commonly referred to just as ``repository'',
is the place where all the material produced within this project will
live.
There is a strong need to maintain an history of development data,
even on plain documentation, whether it is a proprietary file format
describing an UML chart, or some lovely C source code.
Mantaining versioned files for everything makes developers more free to cut,
modify, hack, and revamp them, with the safety that older versions
can always be fetched again.
This document describes some guidelines for maintaining the
repository as clean as possible, by defining some restrictive
rules that developers must respect in order to avoid abusing
of the customizability this tool offers.
@c % --------------------------------------------------
@node Repository layout, Basic svn usage, Introduction and goals, Committing changes
@section Repository layout
@cindex repository
@cindex directory layout
The layout you'll find inside the repository will be:
@table @samp
@item swe/branches
This is the same as tags, except that commits are allowed inside the
branch. Please refer to common development models to decide what
should or should not be done inside a branch. Note that
branching isn't something everybody should do: it should be agreed
together with the project administrator.
The format of a branch is:
@example
<@emph{version_number}>-r<@emph{revision_number}>--<@emph{branch_name}>
@end example
Example:
@example
1.2-r164--guirestyle
@end example
@c -- end swe/branches
@item swe/docs
(@emph{subdirectories}: @samp{internals}, @samp{externals},
@samp{manuals}, @samp{misc})
Contains all drafts intended for the developers. This
directory doesn't support tagging and branching because drafts
has ``eternal'' life. If needs arise, they'll rather need to be
renamed appending their version to their filename (-01, -02, etc.).
@c -- end swe/docs
@item swe/prototypes
A number of explorative prototypes we've set up to assess
availability and workingness of needed technologies.
@c -- end swe/prototypes
@item swe/tags
It contains copies of the @samp{trunk/} directory. Note that
tagging the trunk directory reflects in a double space only
for your local working copy, while it is a @math{O(1)}
operation for the server. Changes and commits are NOT
allowed here. Please note that tagging must be agreeded
with project administrator.
The format of a tag is:
@example
<@emph{version_number}>
@end example
Example:
@example
1.0
@end example
@c -- end swe/tags
@item swe/trunk
(@emph{subdirectories}: @samp{doc}, @samp{src}, @dots{})
This is the main development area where source files are held.
Usually, official releases spin off the trunk.
For a list of the directories layed out therein, please
refer to @ref{Directory overview}.
@c -- end swe/trunk
@end table
@c % --------------------------------------------------
@node Basic svn usage, Gold rules on committing, Repository layout, Committing changes
@section Basic svn usage
@cindex repository
@cindex svn
@cindex locking files
In your daily use of the repository you will mostly need to know a
very small subgroup of svn commands. Other ones are usually for fine
tuning operations (like setting file binary flags, keyword expansion, managing
the repository tree, etc.), which are tasks carried out by the repository
administrator.
Here there's a quick reference about such commands:
@table @samp
@item svn checkout @emph{http://svn.thgnet.it/swe/drafts}
Downloads a copy of the current @samp{drafts/} directory contents.
Checking out the root repository dir (@samp{swe/}) may
result, in near future, to a @strong{big} download, as
branch and tags will be stored inside the root directory.
@item svn update @r{(}@emph{short form}@r{:} svn up@r{)}
Recursively updates the current directory to the
latest revision. Use option @option{-r N} to update to a
specific revision.
@item svn status
Shows the status of @strong{your} working copy against
the repository.
@item svn diff
Shows differences in unified diff format between your working
copy and the base version of the current revision selected
(usually it means the latest). If you want to compare two different
revisions you can add a @option{-r N:M} parameter.
@item svn lock @emph{filename}
Locks a file so that everybody except the lock owner can't commit
over it. This is particularly useful for binary files:
you should always try to acquire a lock before starting editing.
@end table
@c % --------------------------------------------------
@node Gold rules on committing, How to write good log messages, Basic svn usage, Committing changes
@section Gold rules on committing
@cindex committing
A versioning system, by definition, records everything that goes through it.
So it may be a good idea not to commit garbage or make changes that will
probably be rejected by the team. The repository mustn't be used as a
temporary file storage system (so just don't use it to transfer files from
work to home or vice-versa!).
When you commit something, it should be an acceptable piece of work.
Of course, it can happen that later inspection demonstrates
it's better to revert some changesets, but that's the purpose of
having a centralized versioning system.
Avoid big commits altogether. A detailed description of your intentions
should hit the mailing list @emph{before} even starting to write such a
patch. Then, committing your work must happen via
@strong{small incremental patches}.
Also please avoid making structural tree changes (creating,
moving, removing, renaming directories) without asking first
the repository administrator.
Everything can be reverted by @command{svn}, but that's not an
excuse for sloppiness.
@c % --------------------------------------------------
@node How to write good log messages, Conflicts resolution, Gold rules on committing, Committing changes
@section How to write good log messages
@cindex log messages
Be as descriptive as possible, concisely. If your changeset was discussed on
the mailing list or at a meeting, make a clear reference to it.
Please be consistent with the message format. Use a clean english language,
employing only abbreviations contained in the glossary document.
Always prepend a dash (@minus{}) for each changeset description,
followed by a space. This will make clear, in case of line wrapping,
what is part of the list and what is simply a new line.
Every sentence must end with a full stop. If a particular description
is composed by several sub-descriptions, use a colon (@samp{:}), and
use a tab space to indent the inner list.
You can use only one level of nesting for lists. If you need more,
you are probably making an oversized commit.
An example of the log format is the following:
@example
- Change description 1.
- Change description 2:
<tab> - Part 1 of change description 2.
<tab> - Part 2 of change description 2.
- Change description 3. This particular change has a very long message
describing this atomic commit.
@end example
@c % --------------------------------------------------
@node Conflicts resolution, (none), How to write good log messages, Committing changes
@section Conflicts resolution
@cindex conflicts
@cindex merging
As in any other concurrent development system, conflicts may happen.
this will be demanded to the official @cite{Subversion Book (ch. 3 sect. 5.4)}
for an explanation on how to handle them.
We will just quote something to keep well in mind, however:
@quotation
In the end, it all comes down to one critical factor: user communication.
When users communicate poorly, both syntactic and semantic conflicts
increase. No system can force users to communicate perfectly, and no system
can detect semantic conflicts. So there's no point in being lulled into a
false promise that a locking system will somehow prevent conflicts; in
practice, locking seems to inhibit productivity more than anything else.
@end quotation
@cite{Version Control with Subversion, a.k.a. ``The Subversion Book''}
@c % --------------------------------------------------
@c include license text
@node License, Concept index, Committing changes, Top
@include fdl.texi
@c % --------------------------------------------------
@node Concept index, (none), License, Top
@unnumbered Concept Index
@printindex cp
@bye