#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.
#160: Revamp complexes
----------------------------+-----------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: minor | Milestone: Olena 1.0
Component: Milena | Version: 1.0
Keywords: cleanup rename |
----------------------------+-----------------------------------------------
* Move complexes from `mln/core/` to `mln/topo/`.
* The '''dynamic''' access(es) to the set of ''n''-faces of a complex
(e.g., `mln::complex::nfaces(unsigned)`) has (have) a linear complexity!
We should get rid of that. We could create an index at the creation of
the complex, mapping dynamic dimension numbers to the corresponding
(static) mixin/data. Ask Roland for details.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/160>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.