This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Olena, a generic and efficient image processing platform".
The branch next has been updated
via e44073ea19332cde2bdd69ea5eb515d4cfc0e140 (commit)
from fbe0b7f5ec449ab79dfad0b4d285a745f625e41e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
e44073e Fix apps/mesh-segm-skel/io.hh.
-----------------------------------------------------------------------
Summary of changes:
milena/ChangeLog | 6 ++++++
milena/apps/mesh-segm-skel/io.hh | 2 ++
2 files changed, 8 insertions(+), 0 deletions(-)
hooks/post-receive
--
Olena, a generic and efficient image processing platform
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Olena, a generic and efficient image processing platform".
The branch revamp-doc-build has been updated
via 75d3ad83be574c7724c64a4a5bb368579dc93d30 (commit)
via 2c83b3cffdfcb61a883b262f838a30bb5e9d35cb (commit)
via 67329fa81dd02786b86ace2b702ff9d179586d9a (commit)
via 67339bfbfc41528fb4daf61a11b2da9499d75793 (commit)
via 44985028aa2736b98961e514e6163bd813242ccc (commit)
via 9729ffbdabda1a9b3a7255142d1aba8f657d9507 (commit)
via d9609f2b13fbd7dc9c49a04c94c1129ccd56ada3 (commit)
via e54763c030a5e6fea6cc79f593c67e6ace2faf40 (commit)
via ef6cf9cfd139ccdbd613847e8cd8484b0a42aaf5 (commit)
via 8869ca10476286d66734b857661c4a34f082a276 (commit)
via 78b36b9fc99784c296061266e563076364d32808 (commit)
via 6f28095b9a93ce36a0c8acba4122e66e781fd21c (commit)
via 2ec1c8cd1608687b140cc400d6d85c743a8dcdd9 (commit)
via 6e3d7ddfe1e0078353d9206110d28617741de580 (commit)
via 901d8eb33b3fbfd20f438ff367867c25847c0550 (commit)
via 1c035cadf79e9e2853752b01eef1566e1b46de23 (commit)
via bac323e4f97d6d0608f5d9e30ba4876db90b1034 (commit)
from 05b14084768907f50860a979aea5d22fe4502c16 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
75d3ad8 Regen INSTALL using autoreconf.
2c83b3c Move INSTALL's contents to README and HACKING.
67329fa Regen documentation products.
67339bf Remove useless regen actions from bootstrap.
4498502 Have doc/gen-figures-mk generate more Makefile bits.
9729ffb Rework doc/gen-figures-mk a bit.
d9609f2 Add options to boostrap.
e54763c Distribute doc/gen-split-outputs-mk.
ef6cf9c bootstrap: Make a more portable use of mktemp.
8869ca1 Make a more portable use of mktemp.
78b36b9 Sort inputs of generators to make them deterministic w.r.t. outputs.
6f28095 bootstrap: Regen milena/doc/figures.mk.
2ec1c8c Generate the list of figures in the documentation.
6e3d7dd Add a script to generate doc/figures.mk.
901d8eb Use a more uniform style in doc/figures.mk.
1c035ca Prepare doc examples for the automated generation of figures.mk.
bac323e bootstrap: Various fixes.
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 43 ++
HACKING | 95 ++++
INSTALL | 469 +++++++++++++-------
README | 223 +++++++++-
bootstrap | 145 ++++--
milena/ChangeLog | 109 +++++
milena/doc/Makefile.am | 123 ++----
milena/doc/examples/ima2d-rot.cc | 7 +-
milena/doc/examples/labeling-compute.cc | 3 +-
milena/doc/examples/split/ima2d-rot-1.cc.raw | 4 +-
milena/doc/figures.mk | 167 ++++---
milena/doc/figures/fill-subdomain-2.ppm | Bin 206 -> 206 bytes
milena/doc/figures/fill-subdomain-3.ppm | Bin 206 -> 206 bytes
milena/doc/figures/labeling-compute-2.ppm | Bin 206 -> 206 bytes
milena/doc/figures/tuto3_colorize-2.ppm | Bin 191 -> 191 bytes
.../figures/tuto4_genericity_and_algorithms-1.ppm | Bin 12406 -> 12406 bytes
.../figures/tuto4_genericity_and_algorithms-5.ppm | Bin 12406 -> 12406 bytes
.../figures/tuto4_genericity_and_algorithms-7.pgm | 6 -
.../figures/tuto4_genericity_and_algorithms-7.ppm | Bin 24696 -> 0 bytes
.../figures/tuto4_genericity_and_algorithms-8.pgm | 6 -
.../figures/tuto4_genericity_and_algorithms-8.ppm | 6 -
.../figures/tuto4_genericity_and_algorithms-9.pgm | 6 -
.../figures/tuto4_genericity_and_algorithms-9.ppm | 6 -
milena/doc/gen-figures-mk | 192 ++++++++
milena/doc/gen-split-examples-mk | 11 +-
milena/doc/gen-split-outputs-mk | 11 +-
.../{accu-right-instantiation.txt => ima-load.txt} | 0
...t-instantiation.txt => tuto3_first_routine.txt} | 0
...ccu-right-instantiation.txt => tuto4_image.txt} | 0
milena/doc/pbm-figures.mk | 11 -
milena/doc/pgm-figures.mk | 7 -
milena/doc/ppm-figures.mk | 29 --
milena/doc/split-examples.mk | 102 +++---
33 files changed, 1251 insertions(+), 530 deletions(-)
create mode 100644 HACKING
delete mode 100644 milena/doc/figures/tuto4_genericity_and_algorithms-7.pgm
delete mode 100644 milena/doc/figures/tuto4_genericity_and_algorithms-7.ppm
delete mode 100644 milena/doc/figures/tuto4_genericity_and_algorithms-8.pgm
delete mode 100644 milena/doc/figures/tuto4_genericity_and_algorithms-8.ppm
delete mode 100644 milena/doc/figures/tuto4_genericity_and_algorithms-9.pgm
delete mode 100644 milena/doc/figures/tuto4_genericity_and_algorithms-9.ppm
create mode 100755 milena/doc/gen-figures-mk
copy milena/doc/outputs/{accu-right-instantiation.txt => ima-load.txt} (100%)
copy milena/doc/outputs/{accu-right-instantiation.txt => tuto3_first_routine.txt} (100%)
copy milena/doc/outputs/{accu-right-instantiation.txt => tuto4_image.txt} (100%)
delete mode 100644 milena/doc/pbm-figures.mk
delete mode 100644 milena/doc/pgm-figures.mk
delete mode 100644 milena/doc/ppm-figures.mk
hooks/post-receive
--
Olena, a generic and efficient image processing platform
* INSTALL: New.
---
ChangeLog | 6 +
INSTALL | 365 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 INSTALL
diff --git a/ChangeLog b/ChangeLog
index e9622e6..2fe133a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2010-03-22 Roland Levillain <roland(a)lrde.epita.fr>
+ Regen INSTALL using autoreconf.
+
+ * INSTALL: New.
+
+2010-03-22 Roland Levillain <roland(a)lrde.epita.fr>
+
Move INSTALL's contents to README and HACKING.
* INSTALL: Remove this file and move its contents...
diff --git a/INSTALL b/INSTALL
new file mode 100644
index 0000000..7d1c323
--- /dev/null
+++ b/INSTALL
@@ -0,0 +1,365 @@
+Installation Instructions
+*************************
+
+Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
+2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+
+ Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved. This file is offered as-is,
+without warranty of any kind.
+
+Basic Installation
+==================
+
+ Briefly, the shell commands `./configure; make; make install' should
+configure, build, and install this package. The following
+more-detailed instructions are generic; see the `README' file for
+instructions specific to this package. Some packages provide this
+`INSTALL' file but do not implement all of the features documented
+below. The lack of an optional feature in a given package is not
+necessarily a bug. More recommendations for GNU packages can be found
+in *note Makefile Conventions: (standards)Makefile Conventions.
+
+ The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation. It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions. Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, and a
+file `config.log' containing compiler output (useful mainly for
+debugging `configure').
+
+ It can also use an optional file (typically called `config.cache'
+and enabled with `--cache-file=config.cache' or simply `-C') that saves
+the results of its tests to speed up reconfiguring. Caching is
+disabled by default to prevent problems with accidental use of stale
+cache files.
+
+ If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release. If you are using the cache, and at
+some point `config.cache' contains results you don't want to keep, you
+may remove or edit it.
+
+ The file `configure.ac' (or `configure.in') is used to create
+`configure' by a program called `autoconf'. You need `configure.ac' if
+you want to change it or regenerate `configure' using a newer version
+of `autoconf'.
+
+ The simplest way to compile this package is:
+
+ 1. `cd' to the directory containing the package's source code and type
+ `./configure' to configure the package for your system.
+
+ Running `configure' might take a while. While running, it prints
+ some messages telling which features it is checking for.
+
+ 2. Type `make' to compile the package.
+
+ 3. Optionally, type `make check' to run any self-tests that come with
+ the package, generally using the just-built uninstalled binaries.
+
+ 4. Type `make install' to install the programs and any data files and
+ documentation. When installing into a prefix owned by root, it is
+ recommended that the package be configured and built as a regular
+ user, and only the `make install' phase executed with root
+ privileges.
+
+ 5. Optionally, type `make installcheck' to repeat any self-tests, but
+ this time using the binaries in their final installed location.
+ This target does not install anything. Running this target as a
+ regular user, particularly if the prior `make install' required
+ root privileges, verifies that the installation completed
+ correctly.
+
+ 6. You can remove the program binaries and object files from the
+ source code directory by typing `make clean'. To also remove the
+ files that `configure' created (so you can compile the package for
+ a different kind of computer), type `make distclean'. There is
+ also a `make maintainer-clean' target, but that is intended mainly
+ for the package's developers. If you use it, you may have to get
+ all sorts of other programs in order to regenerate files that came
+ with the distribution.
+
+ 7. Often, you can also type `make uninstall' to remove the installed
+ files again. In practice, not all packages have tested that
+ uninstallation works correctly, even though it is required by the
+ GNU Coding Standards.
+
+ 8. Some packages, particularly those that use Automake, provide `make
+ distcheck', which can by used by developers to test that all other
+ targets like `make install' and `make uninstall' work correctly.
+ This target is generally not run by end users.
+
+Compilers and Options
+=====================
+
+ Some systems require unusual options for compilation or linking that
+the `configure' script does not know about. Run `./configure --help'
+for details on some of the pertinent environment variables.
+
+ You can give `configure' initial values for configuration parameters
+by setting variables in the command line or in the environment. Here
+is an example:
+
+ ./configure CC=c99 CFLAGS=-g LIBS=-lposix
+
+ *Note Defining Variables::, for more details.
+
+Compiling For Multiple Architectures
+====================================
+
+ You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory. To do this, you can use GNU `make'. `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script. `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'. This
+is known as a "VPATH" build.
+
+ With a non-GNU `make', it is safer to compile the package for one
+architecture at a time in the source code directory. After you have
+installed the package for one architecture, use `make distclean' before
+reconfiguring for another architecture.
+
+ On MacOS X 10.5 and later systems, you can create libraries and
+executables that work on multiple system types--known as "fat" or
+"universal" binaries--by specifying multiple `-arch' options to the
+compiler but only a single `-arch' option to the preprocessor. Like
+this:
+
+ ./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
+ CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
+ CPP="gcc -E" CXXCPP="g++ -E"
+
+ This is not guaranteed to produce working output in all cases, you
+may have to build one architecture at a time and combine the results
+using the `lipo' tool if you have problems.
+
+Installation Names
+==================
+
+ By default, `make install' installs the package's commands under
+`/usr/local/bin', include files under `/usr/local/include', etc. You
+can specify an installation prefix other than `/usr/local' by giving
+`configure' the option `--prefix=PREFIX', where PREFIX must be an
+absolute file name.
+
+ You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files. If you
+pass the option `--exec-prefix=PREFIX' to `configure', the package uses
+PREFIX as the prefix for installing programs and libraries.
+Documentation and other data files still use the regular prefix.
+
+ In addition, if you use an unusual directory layout you can give
+options like `--bindir=DIR' to specify different values for particular
+kinds of files. Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them. In general, the
+default for these options is expressed in terms of `${prefix}', so that
+specifying just `--prefix' will affect all of the other directory
+specifications that were not explicitly provided.
+
+ The most portable way to affect installation locations is to pass the
+correct locations to `configure'; however, many packages provide one or
+both of the following shortcuts of passing variable assignments to the
+`make install' command line to change installation locations without
+having to reconfigure or recompile.
+
+ The first method involves providing an override variable for each
+affected directory. For example, `make install
+prefix=/alternate/directory' will choose an alternate location for all
+directory configuration variables that were expressed in terms of
+`${prefix}'. Any directories that were specified during `configure',
+but not in terms of `${prefix}', must each be overridden at install
+time for the entire installation to be relocated. The approach of
+makefile variable overrides for each directory variable is required by
+the GNU Coding Standards, and ideally causes no recompilation.
+However, some platforms have known limitations with the semantics of
+shared libraries that end up requiring recompilation when using this
+method, particularly noticeable in packages that use GNU Libtool.
+
+ The second method involves providing the `DESTDIR' variable. For
+example, `make install DESTDIR=/alternate/directory' will prepend
+`/alternate/directory' before all installation names. The approach of
+`DESTDIR' overrides is not required by the GNU Coding Standards, and
+does not work on platforms that have drive letters. On the other hand,
+it does better at avoiding recompilation issues, and works well even
+when some directory options were not specified in terms of `${prefix}'
+at `configure' time.
+
+Optional Features
+=================
+
+ If the package supports it, you can cause programs to be installed
+with an extra prefix or suffix on their names by giving `configure' the
+option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+
+ Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System). The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+ For packages that use the X Window System, `configure' can usually
+find the X include and library files automatically, but if it doesn't,
+you can use the `configure' options `--x-includes=DIR' and
+`--x-libraries=DIR' to specify their locations.
+
+ Some packages offer the ability to configure how verbose the
+execution of `make' will be. For these packages, running `./configure
+--enable-silent-rules' sets the default to minimal output, which can be
+overridden with `make V=1'; while running `./configure
+--disable-silent-rules' sets the default to verbose, which can be
+overridden with `make V=0'.
+
+Particular systems
+==================
+
+ On HP-UX, the default C compiler is not ANSI C compatible. If GNU
+CC is not installed, it is recommended to use the following options in
+order to use an ANSI C compiler:
+
+ ./configure CC="cc -Ae -D_XOPEN_SOURCE=500"
+
+and if that doesn't work, install pre-built binaries of GCC for HP-UX.
+
+ On OSF/1 a.k.a. Tru64, some versions of the default C compiler cannot
+parse its `<wchar.h>' header file. The option `-nodtk' can be used as
+a workaround. If GNU CC is not installed, it is therefore recommended
+to try
+
+ ./configure CC="cc"
+
+and if that doesn't work, try
+
+ ./configure CC="cc -nodtk"
+
+ On Solaris, don't put `/usr/ucb' early in your `PATH'. This
+directory contains several dysfunctional programs; working variants of
+these programs are available in `/usr/bin'. So, if you need `/usr/ucb'
+in your `PATH', put it _after_ `/usr/bin'.
+
+ On Haiku, software installed for all users goes in `/boot/common',
+not `/usr/local'. It is recommended to use the following options:
+
+ ./configure --prefix=/boot/common
+
+Specifying the System Type
+==========================
+
+ There may be some features `configure' cannot figure out
+automatically, but needs to determine by the type of machine the package
+will run on. Usually, assuming the package is built to be run on the
+_same_ architectures, `configure' can figure that out, but if it prints
+a message saying it cannot guess the machine type, give it the
+`--build=TYPE' option. TYPE can either be a short name for the system
+type, such as `sun4', or a canonical name which has the form:
+
+ CPU-COMPANY-SYSTEM
+
+where SYSTEM can have one of these forms:
+
+ OS
+ KERNEL-OS
+
+ See the file `config.sub' for the possible values of each field. If
+`config.sub' isn't included in this package, then this package doesn't
+need to know the machine type.
+
+ If you are _building_ compiler tools for cross-compiling, you should
+use the option `--target=TYPE' to select the type of system they will
+produce code for.
+
+ If you want to _use_ a cross compiler, that generates code for a
+platform different from the build platform, you should specify the
+"host" platform (i.e., that on which the generated programs will
+eventually be run) with `--host=TYPE'.
+
+Sharing Defaults
+================
+
+ If you want to set default values for `configure' scripts to share,
+you can create a site shell script called `config.site' that gives
+default values for variables like `CC', `cache_file', and `prefix'.
+`configure' looks for `PREFIX/share/config.site' if it exists, then
+`PREFIX/etc/config.site' if it exists. Or, you can set the
+`CONFIG_SITE' environment variable to the location of the site script.
+A warning: not all `configure' scripts look for a site script.
+
+Defining Variables
+==================
+
+ Variables not defined in a site shell script can be set in the
+environment passed to `configure'. However, some packages may run
+configure again during the build, and the customized values of these
+variables may be lost. In order to avoid this problem, you should set
+them in the `configure' command line, using `VAR=value'. For example:
+
+ ./configure CC=/usr/local2/bin/gcc
+
+causes the specified `gcc' to be used as the C compiler (unless it is
+overridden in the site shell script).
+
+Unfortunately, this technique does not work for `CONFIG_SHELL' due to
+an Autoconf bug. Until the bug is fixed you can use this workaround:
+
+ CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
+
+`configure' Invocation
+======================
+
+ `configure' recognizes the following options to control how it
+operates.
+
+`--help'
+`-h'
+ Print a summary of all of the options to `configure', and exit.
+
+`--help=short'
+`--help=recursive'
+ Print a summary of the options unique to this package's
+ `configure', and exit. The `short' variant lists options used
+ only in the top level, while the `recursive' variant lists options
+ also present in any nested packages.
+
+`--version'
+`-V'
+ Print the version of Autoconf used to generate the `configure'
+ script, and exit.
+
+`--cache-file=FILE'
+ Enable the cache: use and save the results of the tests in FILE,
+ traditionally `config.cache'. FILE defaults to `/dev/null' to
+ disable caching.
+
+`--config-cache'
+`-C'
+ Alias for `--cache-file=config.cache'.
+
+`--quiet'
+`--silent'
+`-q'
+ Do not print messages saying which checks are being made. To
+ suppress all normal output, redirect it to `/dev/null' (any error
+ messages will still be shown).
+
+`--srcdir=DIR'
+ Look for the package's source code in directory DIR. Usually
+ `configure' can determine that directory automatically.
+
+`--prefix=DIR'
+ Use DIR as the installation prefix. *note Installation Names::
+ for more details, including other options available for fine-tuning
+ the installation locations.
+
+`--no-create'
+`-n'
+ Run the configure checks, but stop before creating any output
+ files.
+
+`configure' also accepts some other, not widely useful, options. Run
+`configure --help' for more details.
+
--
1.5.6.5
* INSTALL: New.
---
ChangeLog | 6 +
INSTALL | 365 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 INSTALL
diff --git a/ChangeLog b/ChangeLog
index 5d57eee..6401ec2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2010-03-22 Roland Levillain <roland(a)lrde.epita.fr>
+ Regen INSTALL using autoreconf.
+
+ * INSTALL: New.
+
+2010-03-22 Roland Levillain <roland(a)lrde.epita.fr>
+
Move INSTALL's contents to README and HACKING.
* INSTALL: Remove this file and move its contents...
diff --git a/INSTALL b/INSTALL
new file mode 100644
index 0000000..7d1c323
--- /dev/null
+++ b/INSTALL
@@ -0,0 +1,365 @@
+Installation Instructions
+*************************
+
+Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
+2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+
+ Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved. This file is offered as-is,
+without warranty of any kind.
+
+Basic Installation
+==================
+
+ Briefly, the shell commands `./configure; make; make install' should
+configure, build, and install this package. The following
+more-detailed instructions are generic; see the `README' file for
+instructions specific to this package. Some packages provide this
+`INSTALL' file but do not implement all of the features documented
+below. The lack of an optional feature in a given package is not
+necessarily a bug. More recommendations for GNU packages can be found
+in *note Makefile Conventions: (standards)Makefile Conventions.
+
+ The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation. It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions. Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, and a
+file `config.log' containing compiler output (useful mainly for
+debugging `configure').
+
+ It can also use an optional file (typically called `config.cache'
+and enabled with `--cache-file=config.cache' or simply `-C') that saves
+the results of its tests to speed up reconfiguring. Caching is
+disabled by default to prevent problems with accidental use of stale
+cache files.
+
+ If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release. If you are using the cache, and at
+some point `config.cache' contains results you don't want to keep, you
+may remove or edit it.
+
+ The file `configure.ac' (or `configure.in') is used to create
+`configure' by a program called `autoconf'. You need `configure.ac' if
+you want to change it or regenerate `configure' using a newer version
+of `autoconf'.
+
+ The simplest way to compile this package is:
+
+ 1. `cd' to the directory containing the package's source code and type
+ `./configure' to configure the package for your system.
+
+ Running `configure' might take a while. While running, it prints
+ some messages telling which features it is checking for.
+
+ 2. Type `make' to compile the package.
+
+ 3. Optionally, type `make check' to run any self-tests that come with
+ the package, generally using the just-built uninstalled binaries.
+
+ 4. Type `make install' to install the programs and any data files and
+ documentation. When installing into a prefix owned by root, it is
+ recommended that the package be configured and built as a regular
+ user, and only the `make install' phase executed with root
+ privileges.
+
+ 5. Optionally, type `make installcheck' to repeat any self-tests, but
+ this time using the binaries in their final installed location.
+ This target does not install anything. Running this target as a
+ regular user, particularly if the prior `make install' required
+ root privileges, verifies that the installation completed
+ correctly.
+
+ 6. You can remove the program binaries and object files from the
+ source code directory by typing `make clean'. To also remove the
+ files that `configure' created (so you can compile the package for
+ a different kind of computer), type `make distclean'. There is
+ also a `make maintainer-clean' target, but that is intended mainly
+ for the package's developers. If you use it, you may have to get
+ all sorts of other programs in order to regenerate files that came
+ with the distribution.
+
+ 7. Often, you can also type `make uninstall' to remove the installed
+ files again. In practice, not all packages have tested that
+ uninstallation works correctly, even though it is required by the
+ GNU Coding Standards.
+
+ 8. Some packages, particularly those that use Automake, provide `make
+ distcheck', which can by used by developers to test that all other
+ targets like `make install' and `make uninstall' work correctly.
+ This target is generally not run by end users.
+
+Compilers and Options
+=====================
+
+ Some systems require unusual options for compilation or linking that
+the `configure' script does not know about. Run `./configure --help'
+for details on some of the pertinent environment variables.
+
+ You can give `configure' initial values for configuration parameters
+by setting variables in the command line or in the environment. Here
+is an example:
+
+ ./configure CC=c99 CFLAGS=-g LIBS=-lposix
+
+ *Note Defining Variables::, for more details.
+
+Compiling For Multiple Architectures
+====================================
+
+ You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory. To do this, you can use GNU `make'. `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script. `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'. This
+is known as a "VPATH" build.
+
+ With a non-GNU `make', it is safer to compile the package for one
+architecture at a time in the source code directory. After you have
+installed the package for one architecture, use `make distclean' before
+reconfiguring for another architecture.
+
+ On MacOS X 10.5 and later systems, you can create libraries and
+executables that work on multiple system types--known as "fat" or
+"universal" binaries--by specifying multiple `-arch' options to the
+compiler but only a single `-arch' option to the preprocessor. Like
+this:
+
+ ./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
+ CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
+ CPP="gcc -E" CXXCPP="g++ -E"
+
+ This is not guaranteed to produce working output in all cases, you
+may have to build one architecture at a time and combine the results
+using the `lipo' tool if you have problems.
+
+Installation Names
+==================
+
+ By default, `make install' installs the package's commands under
+`/usr/local/bin', include files under `/usr/local/include', etc. You
+can specify an installation prefix other than `/usr/local' by giving
+`configure' the option `--prefix=PREFIX', where PREFIX must be an
+absolute file name.
+
+ You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files. If you
+pass the option `--exec-prefix=PREFIX' to `configure', the package uses
+PREFIX as the prefix for installing programs and libraries.
+Documentation and other data files still use the regular prefix.
+
+ In addition, if you use an unusual directory layout you can give
+options like `--bindir=DIR' to specify different values for particular
+kinds of files. Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them. In general, the
+default for these options is expressed in terms of `${prefix}', so that
+specifying just `--prefix' will affect all of the other directory
+specifications that were not explicitly provided.
+
+ The most portable way to affect installation locations is to pass the
+correct locations to `configure'; however, many packages provide one or
+both of the following shortcuts of passing variable assignments to the
+`make install' command line to change installation locations without
+having to reconfigure or recompile.
+
+ The first method involves providing an override variable for each
+affected directory. For example, `make install
+prefix=/alternate/directory' will choose an alternate location for all
+directory configuration variables that were expressed in terms of
+`${prefix}'. Any directories that were specified during `configure',
+but not in terms of `${prefix}', must each be overridden at install
+time for the entire installation to be relocated. The approach of
+makefile variable overrides for each directory variable is required by
+the GNU Coding Standards, and ideally causes no recompilation.
+However, some platforms have known limitations with the semantics of
+shared libraries that end up requiring recompilation when using this
+method, particularly noticeable in packages that use GNU Libtool.
+
+ The second method involves providing the `DESTDIR' variable. For
+example, `make install DESTDIR=/alternate/directory' will prepend
+`/alternate/directory' before all installation names. The approach of
+`DESTDIR' overrides is not required by the GNU Coding Standards, and
+does not work on platforms that have drive letters. On the other hand,
+it does better at avoiding recompilation issues, and works well even
+when some directory options were not specified in terms of `${prefix}'
+at `configure' time.
+
+Optional Features
+=================
+
+ If the package supports it, you can cause programs to be installed
+with an extra prefix or suffix on their names by giving `configure' the
+option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+
+ Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System). The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+ For packages that use the X Window System, `configure' can usually
+find the X include and library files automatically, but if it doesn't,
+you can use the `configure' options `--x-includes=DIR' and
+`--x-libraries=DIR' to specify their locations.
+
+ Some packages offer the ability to configure how verbose the
+execution of `make' will be. For these packages, running `./configure
+--enable-silent-rules' sets the default to minimal output, which can be
+overridden with `make V=1'; while running `./configure
+--disable-silent-rules' sets the default to verbose, which can be
+overridden with `make V=0'.
+
+Particular systems
+==================
+
+ On HP-UX, the default C compiler is not ANSI C compatible. If GNU
+CC is not installed, it is recommended to use the following options in
+order to use an ANSI C compiler:
+
+ ./configure CC="cc -Ae -D_XOPEN_SOURCE=500"
+
+and if that doesn't work, install pre-built binaries of GCC for HP-UX.
+
+ On OSF/1 a.k.a. Tru64, some versions of the default C compiler cannot
+parse its `<wchar.h>' header file. The option `-nodtk' can be used as
+a workaround. If GNU CC is not installed, it is therefore recommended
+to try
+
+ ./configure CC="cc"
+
+and if that doesn't work, try
+
+ ./configure CC="cc -nodtk"
+
+ On Solaris, don't put `/usr/ucb' early in your `PATH'. This
+directory contains several dysfunctional programs; working variants of
+these programs are available in `/usr/bin'. So, if you need `/usr/ucb'
+in your `PATH', put it _after_ `/usr/bin'.
+
+ On Haiku, software installed for all users goes in `/boot/common',
+not `/usr/local'. It is recommended to use the following options:
+
+ ./configure --prefix=/boot/common
+
+Specifying the System Type
+==========================
+
+ There may be some features `configure' cannot figure out
+automatically, but needs to determine by the type of machine the package
+will run on. Usually, assuming the package is built to be run on the
+_same_ architectures, `configure' can figure that out, but if it prints
+a message saying it cannot guess the machine type, give it the
+`--build=TYPE' option. TYPE can either be a short name for the system
+type, such as `sun4', or a canonical name which has the form:
+
+ CPU-COMPANY-SYSTEM
+
+where SYSTEM can have one of these forms:
+
+ OS
+ KERNEL-OS
+
+ See the file `config.sub' for the possible values of each field. If
+`config.sub' isn't included in this package, then this package doesn't
+need to know the machine type.
+
+ If you are _building_ compiler tools for cross-compiling, you should
+use the option `--target=TYPE' to select the type of system they will
+produce code for.
+
+ If you want to _use_ a cross compiler, that generates code for a
+platform different from the build platform, you should specify the
+"host" platform (i.e., that on which the generated programs will
+eventually be run) with `--host=TYPE'.
+
+Sharing Defaults
+================
+
+ If you want to set default values for `configure' scripts to share,
+you can create a site shell script called `config.site' that gives
+default values for variables like `CC', `cache_file', and `prefix'.
+`configure' looks for `PREFIX/share/config.site' if it exists, then
+`PREFIX/etc/config.site' if it exists. Or, you can set the
+`CONFIG_SITE' environment variable to the location of the site script.
+A warning: not all `configure' scripts look for a site script.
+
+Defining Variables
+==================
+
+ Variables not defined in a site shell script can be set in the
+environment passed to `configure'. However, some packages may run
+configure again during the build, and the customized values of these
+variables may be lost. In order to avoid this problem, you should set
+them in the `configure' command line, using `VAR=value'. For example:
+
+ ./configure CC=/usr/local2/bin/gcc
+
+causes the specified `gcc' to be used as the C compiler (unless it is
+overridden in the site shell script).
+
+Unfortunately, this technique does not work for `CONFIG_SHELL' due to
+an Autoconf bug. Until the bug is fixed you can use this workaround:
+
+ CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
+
+`configure' Invocation
+======================
+
+ `configure' recognizes the following options to control how it
+operates.
+
+`--help'
+`-h'
+ Print a summary of all of the options to `configure', and exit.
+
+`--help=short'
+`--help=recursive'
+ Print a summary of the options unique to this package's
+ `configure', and exit. The `short' variant lists options used
+ only in the top level, while the `recursive' variant lists options
+ also present in any nested packages.
+
+`--version'
+`-V'
+ Print the version of Autoconf used to generate the `configure'
+ script, and exit.
+
+`--cache-file=FILE'
+ Enable the cache: use and save the results of the tests in FILE,
+ traditionally `config.cache'. FILE defaults to `/dev/null' to
+ disable caching.
+
+`--config-cache'
+`-C'
+ Alias for `--cache-file=config.cache'.
+
+`--quiet'
+`--silent'
+`-q'
+ Do not print messages saying which checks are being made. To
+ suppress all normal output, redirect it to `/dev/null' (any error
+ messages will still be shown).
+
+`--srcdir=DIR'
+ Look for the package's source code in directory DIR. Usually
+ `configure' can determine that directory automatically.
+
+`--prefix=DIR'
+ Use DIR as the installation prefix. *note Installation Names::
+ for more details, including other options available for fine-tuning
+ the installation locations.
+
+`--no-create'
+`-n'
+ Run the configure checks, but stop before creating any output
+ files.
+
+`configure' also accepts some other, not widely useful, options. Run
+`configure --help' for more details.
+
--
1.5.6.5
* INSTALL: Remove this file and move its contents...
* README: ...here, and...
* HACKING: ...here (new file).
---
ChangeLog | 8 ++
HACKING | 95 ++++++++++++++++++++++++++
INSTALL | 216 -----------------------------------------------------------
README | 223 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------
4 files changed, 305 insertions(+), 237 deletions(-)
create mode 100644 HACKING
delete mode 100644 INSTALL
diff --git a/ChangeLog b/ChangeLog
index 826eb19..e9622e6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2010-03-22 Roland Levillain <roland(a)lrde.epita.fr>
+ Move INSTALL's contents to README and HACKING.
+
+ * INSTALL: Remove this file and move its contents...
+ * README: ...here, and...
+ * HACKING: ...here (new file).
+
+2010-03-22 Roland Levillain <roland(a)lrde.epita.fr>
+
Remove useless regen actions from bootstrap.
* bootstrap (gen_doc_figures): Remove this function, and its uses
diff --git a/HACKING b/HACKING
new file mode 100644
index 0000000..de4e4a1
--- /dev/null
+++ b/HACKING
@@ -0,0 +1,95 @@
+Copyright (C) 2009, 2010 EPITA Research and Development Laboratory (LRDE)
+
+This file is part of Olena.
+
+Olena 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, version 2 of the License.
+
+Olena 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 Olena. If not, see <http://www.gnu.org/licenses/>.
+
+The complete GNU General Public License Notice can also be found in
+the 'COPYING' file in the root directory.
+
+
+=================
+Developer's Guide
+=================
+
+This file gathers some useful information for Olena developers and
+contributors.
+
+
+-------------
+Bootstrapping
+-------------
+
+If you are fetching Olena from its Git repository, you will need to
+run `bootstrap' to build files that are not recorded in the
+repository::
+
+ ./bootstrap
+
+By default, `bootstrap' does not regenerate files that are stored on
+the repository. If you want to refresh them (e.g., because your
+working copy is in a bad state), you can ask boostrap to regenerate
+them::
+
+ ./bootstrap --regen
+
+On a configured tree, you can also use Make to perform the same task::
+
+ make regen
+
+
+-----------------
+Required Software
+-----------------
+
+In addition to the required packages listed in README, you may need
+the following extra programs if you want to work on the Olena project.
+
+ * If you want to make changes anywhere within the project, you will
+ need:
+
+ - GNU Autoconf 2.61
+
+ - GNU Automake 1.10
+
+ - GNU Libtool 1.5.22
+
+ * If you plan to make changes within Swilena, you must have:
+
+ - SWIG 1.3.36
+
+ - Python 2.5
+
+ * If you want to change and/or rebuild the documentation, the
+ following tools are required:
+
+ - Doxygen 1.5.6
+
+ - a fairly recent LaTeX distribution
+
+ - the `listings' LaTeX package
+
+ - the `convert' utility from ImageMagick
+
+ - TeX4ht, to compile the LaTeX documentation into HTML
+
+ - dvipng (required by TeX4ht)
+
+
+Note that `bootstrap' checks for the presence of most of these tools.
+
+
+
+.. Local Variables:
+.. mode: rst
+.. End:
diff --git a/INSTALL b/INSTALL
deleted file mode 100644
index 39196d9..0000000
--- a/INSTALL
+++ /dev/null
@@ -1,216 +0,0 @@
-==================
-Installation Notes
-==================
-
-
-This file contains information about the installation process of Olena.
-
- You can read the `README' file for general information about Olena.
-
-
-Required Software
-=================
-
-Here is a non-exhaustive list of required software required to build
-Olena successfully.
-
- * to compile the user examples:
-
- - a POSIX shell, like Bash
-
- - a decent C++ compiler, like GNU C++
-
- - a `make' utility, like GNU `make'
-
-Optional:
-
- * to (re)compile the documentation:
-
- - a LaTeX distribution
-
- - the `listings' TeX package
-
- - the utility `convert' from ImageMagick
-
- - `hevea', a TeX to HTML conversion tool
-
- - latex2html
-
- * to use various image types:
-
- - Magick++
-
- - libtiff
-
- - GDCM
-
- * to develop _within_ Olena:
-
- - GNU Autoconf 2.61
-
- - GNU Automake 1.10
-
- - GNU Libtool 1.5.22
-
- * to develop _within_ Swilena:
-
- - SWIG
-
- - Python
-
-
-Configuration
-=============
-
-In order to prepare the build process, you need to configure the source
-tree.
-
- Assuming your Olena distribution is uncompressed in directory
-`olena-1.0', follow these steps:
-
- % cd olena-1.0
- % mkdir _build
- % cd _build
- % ../configure
-
- The build process can be altered by a number of options you can pass
-to the `configure' script. The following sections describe them.
-
- Additionally, if you are an Olena maintainer (a person who runs
-`make distcheck'), _prefer setting `CXXFLAGS' as an environment
-variable_: the flags given on the command line to `configure' are not
-propagated to recursive runs by `make distcheck'. Or better: use the
-environment CONFIG_SITE to set up a configuration environment (see
-Autoconf's manual).
-
-
-Installation Path
------------------
-
-By default, Olena is installed in the standard "local" directory of
-your system. This is usually `/usr/local' under Unix.
-
- You can change this path with the following flag:
-
- --prefix=<installation prefix>
-
-
-Compiler Selection and Compilation Flags
-----------------------------------------
-
-By default, `configure' will try to use the first C++ compiler it
-encounters on your system. If `CXX' is not set, it will look, in order,
-for:
-
- - the value of the `CCC' environment variable,
-
- - the GNU C++ compiler (`g++'),
-
- - the `c++' or `gpp' commands on your system,
-
- - `aCC', the HP-UX standard C++ compiler,
-
- - the `CC', `cxx', `cc++' or `cl' commands on your system,
-
- - KAI's C++ compiler (`KCC'),
-
- - `RCC', `xlC_r' or `xlC'.
-
- You can override the detection system by passing your favorite
-compiler name to `configure', as follows:
-
- % ../configure CXX=<your-favorite-C++-compiler>
-
- As an alternative, you can also set the environment variable `CXX'.
-
-
- For some compilers (GNU g++ and Intel's icpc to some extent) ,
-`configure' will use default CXXFLAGS. You can override the default
-C++ flags by giving `configure' your selection of flags:
-
- % ../configure CXXFLAGS="<your-favorite-flags>"
-
-
-Additional Components
-=====================
-
-In additional to Milena, several build targets can be enabled. These
-parts are called "components", and you can obtain a list of them by
-running:
-
- % ../configure --help
-
-Olena ships with Trimesh, a third-party library that we have been
-using to manipulate 3D meshes. Eventually, we will drop Trimesh from
-the distribution.
-
-See README for more information on additional components.
-
-
-Building
-========
-
-Once your build directory is `configure'd, you can run
-
- % make
-
-to recursively build all the selected components.
-
-
- Additionally, you can build and run the test suite with:
-
- % make check
-
-However, this process is time- and memory- consuming, and you probably
-do not need it except if you are developing/debugging Olena.
-
-
-Compiler Notes
-==============
-
-Olena has been tested on the following configurations:
-
-System Compiler
-GNU/Linux on IA-32 g++ (GNU GCC) 3.3, 3.4, 4.0, 4.1, 4.2 and 4.3
-GNU/Linux on IA-32 icpc (Intel C/C++ Compiler) 10.1 and 11.0
-GNU/Linux on AMD64/Intel 64 g++ (GNU GCC) 4.1
-Mac OS X (10.5) on IA-32 g++ (GNU GCC) 4.0.1
-
-
-Installing
-==========
-
-To install the Olena headers and additional files on your system, run:
-
- % make install
-
-from the build directory.
-
- If not overridden with `--prefix', this will install:
-
- * the headers in `/usr/local/include/mln/',
-
- * some applications and tools in `/usr/local/bin/',
-
- * sample images and meshes in `/usr/local/share/olena/images/',
-
- * the documentation in `/usr/local/share/doc/olena/`
-
-And optionally:
-
- * Swilena's Python bindings in `/usr/local/lib/python2.x/site-packages/',
-
- * Trimesh programs in `/usr/local/bin/',
-
- * Trimesh libraries in `/usr/local/lib/',
-
- * Trimesh headers in `/usr/local/share/trimesh/',
-
-
- You can later remove Olena from your system by running
-
- % make uninstall
-
-from the build directory (if you have kept it). We recommend the use
-of GNU Stow (or any similar program) during the installation of Olena,
-to make the uninstallation of Olena easier.
diff --git a/README b/README
index 41c65cc..cf35e0a 100644
--- a/README
+++ b/README
@@ -1,4 +1,5 @@
-Copyright (C) 2009 EPITA Research and Development Laboratory (LRDE)
+Copyright (C) 2008, 2009, 2010 EPITA Research and Development
+Laboratory (LRDE)
This file is part of Olena.
@@ -27,8 +28,9 @@ Olena_, a platform dedicated to image processing.
.. _Olena: http://olena.lrde.epita.fr
+--------
Overview
-========
+--------
Olena is a platform dedicated to image processing. At the moment it is
mainly composed of a C++ library: Milena. This library features many
@@ -68,15 +70,46 @@ code or e-mail us.
<http://olena.lrde.epita.fr>.
-Installation
-============
+-----------------
+Required Software
+-----------------
+
+Here is a non-exhaustive list of required software required to build
+Olena successfully.
+
+ * to compile the user examples:
+
+ - a POSIX shell, like Bash
+
+ - a decent C++ compiler, like GNU C++
+
+ - a `make' utility, like GNU `make'
+
+Optional:
+
+ * to use various image types:
+
+ - Magick++
-To install Olena on your system, create a `build' directory (even
+ - libtiff
+
+ - GDCM
+
+
+==================
+Quick Start Manual
+==================
+
+This section summarizes the installation procedure. For more
+information about building and installing Olena, see the next
+sections.
+
+To install Olena on your system, create a `_build' directory (even
though it is not mandatory) and type in the classical sequence at the
command prompt::
- mkdir build
- cd build
+ mkdir _build
+ cd _build
../configure
make
make install (as root)
@@ -94,12 +127,94 @@ Between ``make`` and ``make install``, you may also want to run::
Running the test suite may require up several hours.
-Please read the INSTALL file for more information about building and
-installing Olena.
+=====================
+Detailed Instructions
+=====================
+
+-------------
+Configuration
+-------------
+
+In order to prepare the build process, you need to configure the source
+tree.
+
+ Assuming your Olena distribution is uncompressed in directory
+`olena-1.0', follow these steps:
+
+ % cd olena-1.0
+ % mkdir _build
+ % cd _build
+ % ../configure
+
+ The build process can be altered by a number of options you can pass
+to the `configure' script. The following sections describe them.
+
+ Additionally, if you are an Olena maintainer (a person who runs
+`make distcheck'), _prefer setting `CXXFLAGS' as an environment
+variable_: the flags given on the command line to `configure' are not
+propagated to recursive runs by `make distcheck'. Or better: use the
+environment CONFIG_SITE to set up a configuration environment (see
+Autoconf's manual).
+
+
+Installation Path
+=================
+
+By default, Olena is installed in the standard "local" directory of
+your system. This is usually `/usr/local' under Unix.
+
+ You can change this path with the following flag:
+
+ --prefix=<installation prefix>
+
+
+Compiler Selection and Compilation Flags
+========================================
+
+By default, `configure' will try to use the first C++ compiler it
+encounters on your system. If `CXX' is not set, it will look, in order,
+for:
+
+ - the value of the `CCC' environment variable,
+
+ - the GNU C++ compiler (`g++'),
+
+ - the `c++' or `gpp' commands on your system,
+
+ - `aCC', the HP-UX standard C++ compiler,
+
+ - the `CC', `cxx', `cc++' or `cl' commands on your system,
+
+ - KAI's C++ compiler (`KCC'),
+
+ - `RCC', `xlC_r' or `xlC'.
+
+ You can override the detection system by passing your favorite
+compiler name to `configure', as follows:
+
+ % ../configure CXX=<your-favorite-C++-compiler>
+
+ As an alternative, you can also set the environment variable `CXX'.
+
+ For some compilers (GNU g++ and Intel's icpc to some extent) ,
+`configure' will use default CXXFLAGS. You can override the default
+C++ flags by giving `configure' your selection of flags:
-Additional Features
--------------------
+ % ../configure CXXFLAGS="<your-favorite-flags>"
+
+
+Additional Components
+=====================
+
+In additional to Milena, several build targets can be enabled. These
+parts are called "components", and you can obtain a list of them by
+running:
+
+ % ../configure --help
+
+Swilena
+-------
Swilena is an optional component of Olena exposing Milena to other
languages thanks to the Simplified Wrapper and Interface Generator
@@ -117,22 +232,32 @@ To enable the installation of this module use::
./configure --enable-swilena
+Tools
+-----
+
Sample tools are shipped with the tarball. To enable the installation of
these tools use::
./configure --enable-tools
+Applications
+------------
Sample applications are shipped with the tarball. To enable the
installation of these applications use::
./configure --enable-apps
-Olena ships with Trimesh, a third-party library that we have been
-using to manipulate 3D meshes. Eventually, we will drop Trimesh from
-the distribution. To enable it, use::
+Trimesh
+-------
+
+Trimesh, a third-party library that we have been using to manipulate
+3D meshes, is shipped with Olena. (We will probably drop Trimesh from
+the distribution someday.) To enable it, use::
./configure --enable-trimesh
+Input/output libraries
+----------------------
To read/write TIFF images with Olena, libtiff is required. If
``configure`` is unable to find libtiff on your system, you can help
@@ -140,7 +265,6 @@ it by specifying the base directory of libtiff, e.g.::
./configure --with-tiff=/usr/local
-
To read/write DICOM images with Olena, GDCM is required. Likewise,
you can tell ``configure`` where to find it by giving its install
prefix, e.g.::
@@ -154,8 +278,67 @@ needed) at configuration time::
./configure --with-magickxx=/usr/local/
+--------
+Building
+--------
+
+Once your build directory is `configure'd, you can run
+
+ % make
+
+to recursively build all the selected components.
+
+
+ Additionally, you can build and run the test suite with:
+
+ % make check
+
+However, this process is time- and memory- consuming, and you probably
+do not need it except if you are developing/debugging Olena.
+
+
+----------
+Installing
+----------
+
+To install the Olena headers and additional files on your system, run:
+
+ % make install
+
+from the build directory.
+
+ If not overridden with `--prefix', this will install:
+
+ * the headers in `/usr/local/include/mln/',
+
+ * some applications and tools in `/usr/local/bin/',
+
+ * sample images and meshes in `/usr/local/share/olena/images/',
+
+ * the documentation in `/usr/local/share/doc/olena/`
+
+And optionally:
+
+ * Swilena's Python bindings in `/usr/local/lib/python2.x/site-packages/',
+
+ * Trimesh programs in `/usr/local/bin/',
+
+ * Trimesh libraries in `/usr/local/lib/',
+
+ * Trimesh headers in `/usr/local/share/trimesh/',
+
+
+ You can later remove Olena from your system by running
+
+ % make uninstall
+
+from the build directory (if you have kept it). We recommend the use
+of GNU Stow (or any similar program) during the installation of Olena,
+to make the uninstallation of Olena easier.
+
+=====================
Layout of the Tarball
----------------------
+=====================
The Olena project directory layout is as follows:
@@ -166,7 +349,6 @@ build-aux
external
Sources of Shipped dependencies.
-
m4
Extra Autoconf macros.
@@ -196,16 +378,15 @@ milena
demos
Demos of Milena.
-
swilena
-
python
Some Python bindings for Milena.
-Requirements
-============
+===================
+Supported Platforms
+===================
Olena has been tested on the following configurations:
--
1.5.6.5
* INSTALL: Remove this file and move its contents...
* README: ...here, and...
* HACKING: ...here (new file).
---
ChangeLog | 8 ++
HACKING | 95 ++++++++++++++++++++++++++
INSTALL | 216 -----------------------------------------------------------
README | 223 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------
4 files changed, 305 insertions(+), 237 deletions(-)
create mode 100644 HACKING
delete mode 100644 INSTALL
diff --git a/ChangeLog b/ChangeLog
index 94dd844..5d57eee 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2010-03-22 Roland Levillain <roland(a)lrde.epita.fr>
+ Move INSTALL's contents to README and HACKING.
+
+ * INSTALL: Remove this file and move its contents...
+ * README: ...here, and...
+ * HACKING: ...here (new file).
+
+2010-03-22 Roland Levillain <roland(a)lrde.epita.fr>
+
Remove useless regen actions from bootstrap.
* bootstrap (gen_doc_figures): Remove this function, and its uses
diff --git a/HACKING b/HACKING
new file mode 100644
index 0000000..de4e4a1
--- /dev/null
+++ b/HACKING
@@ -0,0 +1,95 @@
+Copyright (C) 2009, 2010 EPITA Research and Development Laboratory (LRDE)
+
+This file is part of Olena.
+
+Olena 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, version 2 of the License.
+
+Olena 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 Olena. If not, see <http://www.gnu.org/licenses/>.
+
+The complete GNU General Public License Notice can also be found in
+the 'COPYING' file in the root directory.
+
+
+=================
+Developer's Guide
+=================
+
+This file gathers some useful information for Olena developers and
+contributors.
+
+
+-------------
+Bootstrapping
+-------------
+
+If you are fetching Olena from its Git repository, you will need to
+run `bootstrap' to build files that are not recorded in the
+repository::
+
+ ./bootstrap
+
+By default, `bootstrap' does not regenerate files that are stored on
+the repository. If you want to refresh them (e.g., because your
+working copy is in a bad state), you can ask boostrap to regenerate
+them::
+
+ ./bootstrap --regen
+
+On a configured tree, you can also use Make to perform the same task::
+
+ make regen
+
+
+-----------------
+Required Software
+-----------------
+
+In addition to the required packages listed in README, you may need
+the following extra programs if you want to work on the Olena project.
+
+ * If you want to make changes anywhere within the project, you will
+ need:
+
+ - GNU Autoconf 2.61
+
+ - GNU Automake 1.10
+
+ - GNU Libtool 1.5.22
+
+ * If you plan to make changes within Swilena, you must have:
+
+ - SWIG 1.3.36
+
+ - Python 2.5
+
+ * If you want to change and/or rebuild the documentation, the
+ following tools are required:
+
+ - Doxygen 1.5.6
+
+ - a fairly recent LaTeX distribution
+
+ - the `listings' LaTeX package
+
+ - the `convert' utility from ImageMagick
+
+ - TeX4ht, to compile the LaTeX documentation into HTML
+
+ - dvipng (required by TeX4ht)
+
+
+Note that `bootstrap' checks for the presence of most of these tools.
+
+
+
+.. Local Variables:
+.. mode: rst
+.. End:
diff --git a/INSTALL b/INSTALL
deleted file mode 100644
index 39196d9..0000000
--- a/INSTALL
+++ /dev/null
@@ -1,216 +0,0 @@
-==================
-Installation Notes
-==================
-
-
-This file contains information about the installation process of Olena.
-
- You can read the `README' file for general information about Olena.
-
-
-Required Software
-=================
-
-Here is a non-exhaustive list of required software required to build
-Olena successfully.
-
- * to compile the user examples:
-
- - a POSIX shell, like Bash
-
- - a decent C++ compiler, like GNU C++
-
- - a `make' utility, like GNU `make'
-
-Optional:
-
- * to (re)compile the documentation:
-
- - a LaTeX distribution
-
- - the `listings' TeX package
-
- - the utility `convert' from ImageMagick
-
- - `hevea', a TeX to HTML conversion tool
-
- - latex2html
-
- * to use various image types:
-
- - Magick++
-
- - libtiff
-
- - GDCM
-
- * to develop _within_ Olena:
-
- - GNU Autoconf 2.61
-
- - GNU Automake 1.10
-
- - GNU Libtool 1.5.22
-
- * to develop _within_ Swilena:
-
- - SWIG
-
- - Python
-
-
-Configuration
-=============
-
-In order to prepare the build process, you need to configure the source
-tree.
-
- Assuming your Olena distribution is uncompressed in directory
-`olena-1.0', follow these steps:
-
- % cd olena-1.0
- % mkdir _build
- % cd _build
- % ../configure
-
- The build process can be altered by a number of options you can pass
-to the `configure' script. The following sections describe them.
-
- Additionally, if you are an Olena maintainer (a person who runs
-`make distcheck'), _prefer setting `CXXFLAGS' as an environment
-variable_: the flags given on the command line to `configure' are not
-propagated to recursive runs by `make distcheck'. Or better: use the
-environment CONFIG_SITE to set up a configuration environment (see
-Autoconf's manual).
-
-
-Installation Path
------------------
-
-By default, Olena is installed in the standard "local" directory of
-your system. This is usually `/usr/local' under Unix.
-
- You can change this path with the following flag:
-
- --prefix=<installation prefix>
-
-
-Compiler Selection and Compilation Flags
-----------------------------------------
-
-By default, `configure' will try to use the first C++ compiler it
-encounters on your system. If `CXX' is not set, it will look, in order,
-for:
-
- - the value of the `CCC' environment variable,
-
- - the GNU C++ compiler (`g++'),
-
- - the `c++' or `gpp' commands on your system,
-
- - `aCC', the HP-UX standard C++ compiler,
-
- - the `CC', `cxx', `cc++' or `cl' commands on your system,
-
- - KAI's C++ compiler (`KCC'),
-
- - `RCC', `xlC_r' or `xlC'.
-
- You can override the detection system by passing your favorite
-compiler name to `configure', as follows:
-
- % ../configure CXX=<your-favorite-C++-compiler>
-
- As an alternative, you can also set the environment variable `CXX'.
-
-
- For some compilers (GNU g++ and Intel's icpc to some extent) ,
-`configure' will use default CXXFLAGS. You can override the default
-C++ flags by giving `configure' your selection of flags:
-
- % ../configure CXXFLAGS="<your-favorite-flags>"
-
-
-Additional Components
-=====================
-
-In additional to Milena, several build targets can be enabled. These
-parts are called "components", and you can obtain a list of them by
-running:
-
- % ../configure --help
-
-Olena ships with Trimesh, a third-party library that we have been
-using to manipulate 3D meshes. Eventually, we will drop Trimesh from
-the distribution.
-
-See README for more information on additional components.
-
-
-Building
-========
-
-Once your build directory is `configure'd, you can run
-
- % make
-
-to recursively build all the selected components.
-
-
- Additionally, you can build and run the test suite with:
-
- % make check
-
-However, this process is time- and memory- consuming, and you probably
-do not need it except if you are developing/debugging Olena.
-
-
-Compiler Notes
-==============
-
-Olena has been tested on the following configurations:
-
-System Compiler
-GNU/Linux on IA-32 g++ (GNU GCC) 3.3, 3.4, 4.0, 4.1, 4.2 and 4.3
-GNU/Linux on IA-32 icpc (Intel C/C++ Compiler) 10.1 and 11.0
-GNU/Linux on AMD64/Intel 64 g++ (GNU GCC) 4.1
-Mac OS X (10.5) on IA-32 g++ (GNU GCC) 4.0.1
-
-
-Installing
-==========
-
-To install the Olena headers and additional files on your system, run:
-
- % make install
-
-from the build directory.
-
- If not overridden with `--prefix', this will install:
-
- * the headers in `/usr/local/include/mln/',
-
- * some applications and tools in `/usr/local/bin/',
-
- * sample images and meshes in `/usr/local/share/olena/images/',
-
- * the documentation in `/usr/local/share/doc/olena/`
-
-And optionally:
-
- * Swilena's Python bindings in `/usr/local/lib/python2.x/site-packages/',
-
- * Trimesh programs in `/usr/local/bin/',
-
- * Trimesh libraries in `/usr/local/lib/',
-
- * Trimesh headers in `/usr/local/share/trimesh/',
-
-
- You can later remove Olena from your system by running
-
- % make uninstall
-
-from the build directory (if you have kept it). We recommend the use
-of GNU Stow (or any similar program) during the installation of Olena,
-to make the uninstallation of Olena easier.
diff --git a/README b/README
index 41c65cc..cf35e0a 100644
--- a/README
+++ b/README
@@ -1,4 +1,5 @@
-Copyright (C) 2009 EPITA Research and Development Laboratory (LRDE)
+Copyright (C) 2008, 2009, 2010 EPITA Research and Development
+Laboratory (LRDE)
This file is part of Olena.
@@ -27,8 +28,9 @@ Olena_, a platform dedicated to image processing.
.. _Olena: http://olena.lrde.epita.fr
+--------
Overview
-========
+--------
Olena is a platform dedicated to image processing. At the moment it is
mainly composed of a C++ library: Milena. This library features many
@@ -68,15 +70,46 @@ code or e-mail us.
<http://olena.lrde.epita.fr>.
-Installation
-============
+-----------------
+Required Software
+-----------------
+
+Here is a non-exhaustive list of required software required to build
+Olena successfully.
+
+ * to compile the user examples:
+
+ - a POSIX shell, like Bash
+
+ - a decent C++ compiler, like GNU C++
+
+ - a `make' utility, like GNU `make'
+
+Optional:
+
+ * to use various image types:
+
+ - Magick++
-To install Olena on your system, create a `build' directory (even
+ - libtiff
+
+ - GDCM
+
+
+==================
+Quick Start Manual
+==================
+
+This section summarizes the installation procedure. For more
+information about building and installing Olena, see the next
+sections.
+
+To install Olena on your system, create a `_build' directory (even
though it is not mandatory) and type in the classical sequence at the
command prompt::
- mkdir build
- cd build
+ mkdir _build
+ cd _build
../configure
make
make install (as root)
@@ -94,12 +127,94 @@ Between ``make`` and ``make install``, you may also want to run::
Running the test suite may require up several hours.
-Please read the INSTALL file for more information about building and
-installing Olena.
+=====================
+Detailed Instructions
+=====================
+
+-------------
+Configuration
+-------------
+
+In order to prepare the build process, you need to configure the source
+tree.
+
+ Assuming your Olena distribution is uncompressed in directory
+`olena-1.0', follow these steps:
+
+ % cd olena-1.0
+ % mkdir _build
+ % cd _build
+ % ../configure
+
+ The build process can be altered by a number of options you can pass
+to the `configure' script. The following sections describe them.
+
+ Additionally, if you are an Olena maintainer (a person who runs
+`make distcheck'), _prefer setting `CXXFLAGS' as an environment
+variable_: the flags given on the command line to `configure' are not
+propagated to recursive runs by `make distcheck'. Or better: use the
+environment CONFIG_SITE to set up a configuration environment (see
+Autoconf's manual).
+
+
+Installation Path
+=================
+
+By default, Olena is installed in the standard "local" directory of
+your system. This is usually `/usr/local' under Unix.
+
+ You can change this path with the following flag:
+
+ --prefix=<installation prefix>
+
+
+Compiler Selection and Compilation Flags
+========================================
+
+By default, `configure' will try to use the first C++ compiler it
+encounters on your system. If `CXX' is not set, it will look, in order,
+for:
+
+ - the value of the `CCC' environment variable,
+
+ - the GNU C++ compiler (`g++'),
+
+ - the `c++' or `gpp' commands on your system,
+
+ - `aCC', the HP-UX standard C++ compiler,
+
+ - the `CC', `cxx', `cc++' or `cl' commands on your system,
+
+ - KAI's C++ compiler (`KCC'),
+
+ - `RCC', `xlC_r' or `xlC'.
+
+ You can override the detection system by passing your favorite
+compiler name to `configure', as follows:
+
+ % ../configure CXX=<your-favorite-C++-compiler>
+
+ As an alternative, you can also set the environment variable `CXX'.
+
+ For some compilers (GNU g++ and Intel's icpc to some extent) ,
+`configure' will use default CXXFLAGS. You can override the default
+C++ flags by giving `configure' your selection of flags:
-Additional Features
--------------------
+ % ../configure CXXFLAGS="<your-favorite-flags>"
+
+
+Additional Components
+=====================
+
+In additional to Milena, several build targets can be enabled. These
+parts are called "components", and you can obtain a list of them by
+running:
+
+ % ../configure --help
+
+Swilena
+-------
Swilena is an optional component of Olena exposing Milena to other
languages thanks to the Simplified Wrapper and Interface Generator
@@ -117,22 +232,32 @@ To enable the installation of this module use::
./configure --enable-swilena
+Tools
+-----
+
Sample tools are shipped with the tarball. To enable the installation of
these tools use::
./configure --enable-tools
+Applications
+------------
Sample applications are shipped with the tarball. To enable the
installation of these applications use::
./configure --enable-apps
-Olena ships with Trimesh, a third-party library that we have been
-using to manipulate 3D meshes. Eventually, we will drop Trimesh from
-the distribution. To enable it, use::
+Trimesh
+-------
+
+Trimesh, a third-party library that we have been using to manipulate
+3D meshes, is shipped with Olena. (We will probably drop Trimesh from
+the distribution someday.) To enable it, use::
./configure --enable-trimesh
+Input/output libraries
+----------------------
To read/write TIFF images with Olena, libtiff is required. If
``configure`` is unable to find libtiff on your system, you can help
@@ -140,7 +265,6 @@ it by specifying the base directory of libtiff, e.g.::
./configure --with-tiff=/usr/local
-
To read/write DICOM images with Olena, GDCM is required. Likewise,
you can tell ``configure`` where to find it by giving its install
prefix, e.g.::
@@ -154,8 +278,67 @@ needed) at configuration time::
./configure --with-magickxx=/usr/local/
+--------
+Building
+--------
+
+Once your build directory is `configure'd, you can run
+
+ % make
+
+to recursively build all the selected components.
+
+
+ Additionally, you can build and run the test suite with:
+
+ % make check
+
+However, this process is time- and memory- consuming, and you probably
+do not need it except if you are developing/debugging Olena.
+
+
+----------
+Installing
+----------
+
+To install the Olena headers and additional files on your system, run:
+
+ % make install
+
+from the build directory.
+
+ If not overridden with `--prefix', this will install:
+
+ * the headers in `/usr/local/include/mln/',
+
+ * some applications and tools in `/usr/local/bin/',
+
+ * sample images and meshes in `/usr/local/share/olena/images/',
+
+ * the documentation in `/usr/local/share/doc/olena/`
+
+And optionally:
+
+ * Swilena's Python bindings in `/usr/local/lib/python2.x/site-packages/',
+
+ * Trimesh programs in `/usr/local/bin/',
+
+ * Trimesh libraries in `/usr/local/lib/',
+
+ * Trimesh headers in `/usr/local/share/trimesh/',
+
+
+ You can later remove Olena from your system by running
+
+ % make uninstall
+
+from the build directory (if you have kept it). We recommend the use
+of GNU Stow (or any similar program) during the installation of Olena,
+to make the uninstallation of Olena easier.
+
+=====================
Layout of the Tarball
----------------------
+=====================
The Olena project directory layout is as follows:
@@ -166,7 +349,6 @@ build-aux
external
Sources of Shipped dependencies.
-
m4
Extra Autoconf macros.
@@ -196,16 +378,15 @@ milena
demos
Demos of Milena.
-
swilena
-
python
Some Python bindings for Milena.
-Requirements
-============
+===================
+Supported Platforms
+===================
Olena has been tested on the following configurations:
--
1.5.6.5