#199: Stop using recursive Makefiles in milena/tests/?
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: proposal | Status: new
Priority: trivial | Milestone: Olena 1.1
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
This is an open debate, not a well-defined task.
As of r3946, there are more than a hundred `Makefile`s under
source:trunk/milena/tests/. This has a huge impact on configuration and
build times.
Akim suggests we use `Makefile` inclusions instead of `Makefile` recursion
to speed up things. This also means losing the possibility to invoke
`make` in a specific subdirectory of `milena/tests/`, which is very handy.
Akim says we can substitute the feature by using scripts relying on the
control version program (http://lists.gnu.org/archive/html/automake-
patches/2009-03/msg00079.html).
Let's discuss this, and see what we can do after the 1.0 release.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/199>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#221: Post-Olena 1.0 cleanup
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: major | Milestone: Olena 1.1
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
As a memo, an unordered list of miscellaneous tasks (split/reorder if
needed):
* Rename directories `{milena,scribo}/tests/unit_test` as
`{milena,scribo}/tests/unit-tests`.
* Move `milena/tests/tools/*` into `build-aux/`.
* Write a developer Manual (see Vaucanson's).
* All LaTeX-based documents (including the tutorial) should be compiled
with `texi2dvi`.
* The test `tests/io/pgm/pgm.cc` is too long (edit: check that again);
simplify it?
* More generally, we should time tests to see which ones are the most
time-consuming, both at compile- (if applicable) and run-time.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/221>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#134: Overhaul the generation of the documentation
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: major | Milestone: Olena 1.0ß
Component: Milena | Version: 1.0
Keywords: doc |
-------------------------+--------------------------------------------------
Changes introduced in r1606 downgraded many features that were present
before! In particular, source:trunk/milena/doc/Doxyfile.in has been
downgraded from Doxygen version 1.5.2 to Doxygen 1.5.1 (why!?).
Let's start again on a sound basis. The best way is probably to reused
`Doxyfile.in` from a previous revision (e.g,
source:trunk/milena/doc/Doxyfile.in#1476), and add current features (e.g.,
double documentation generation).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/134>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#213: Fix the build system to have « make -j » work
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: major | Milestone: Olena 1.1
Component: Milena | Version: 2.0
Keywords: |
----------------------+-----------------------------------------------------
We cannot safely use parallel make (`make -j`''n'') with current build
system, mainly because of `milena/doc/*`. Once this part is revamped,
ensure `make -j2` (or more) works.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/213>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#203: Document commit procedures
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: levill_r
Type: task | Status: new
Priority: critical | Milestone:
Component: Trac | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
There are just too many mistakes in commits. The LRDE Guidelines warns
about many of them, but IMHO it is not enough.
A draft summary:
* Read comments from other about your patches (and patch proposals), and
take them into account.
* Use tools, but don't be fooled by them (know their limits): Vcs, `svn-
wrapper`, etc. A flaw in a tool is not an excuse for a dirty patch.
* Learn what a (good) !ChangeLog entry is.
* Kwow why !ChangeLogs matter (whatever their form), both technically
and legally.
* Learn how to fix !ChangeLogs correctly.
* Resist to the temptation to commit too fast.
* Don't break things: run `make` (and possibly `make check`) before
committing.
* Do not commit too many things at once: one idea/one task = one
commit.
* Reread you patches before sending them.
* Use ispell (when writing documentation).
* Learn how to use `git-svn` (or `git`, if it is available) instead of
`svn`.
* Learn from others: some tools take time to understand and master (Make,
Autoconf, Automake, shells, etc.).
Olena Teammates shall print and read this page once complete.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/203>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#215: Clean up and integrate the Topological Watershed Transform
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: major | Milestone: Olena 1.1
Component: Milena | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Alexandre Abraham's implementation of the Topological WST is working (see
an example of use in source:trunk/milena/sandbox/roland/constrained-
connectivity.cc) but there are a few issues here and there (notably w.r.t.
genericity). Clean it up, and move it to
source:trunk/milena/mln/morpho/watershed/.
Do not forget to tag the initial file as outdated in the sandbox (or even
to remove it).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/215>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#147: Write a script to automatically generate file skeletons for Olena
-----------------------+----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: trivial | Milestone:
Component: Milena | Version: 1.0
Keywords: generator |
-----------------------+----------------------------------------------------
A Ruby script would be nice, but the language doesn't really matter.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/147>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#238: Have Swilena be compatible with (also) Python 2.6 (and greater)
-------------------------+--------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Swilena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Swilena does not work with Python 2.6 (and probably greater versions).
Swig seems to generates wrappers correctly, and they compile fine, but
tests fail at run time.
There may have been changes in Python's API between versions 2.5 and 2.6
(perhaps iterators?). Investigate.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/238>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.