[ODE] autoconf/automake

[Russ Smith]

> there is autogenerated code which must be compiled with -01
> why must it be compiled with O1 ?

that is numerical code that is generated by fbuild. O1 optimization is
used to preserve the operation orders that were discovered by fbuild to
be the fastest on that platform. believe it or not, O2 makes this code
run much slower for most compilers.

> when do we have to do something in fbuild ?

when the numerical source files must be regenerated for a new platform.
there are two parts to fbuild.
  (1) discover the best set of code generation parameters for a
      particular platform. this only needs to be done once per
      platform, and the resulting files (ParametersX.platform_name)
      should become part of the standard distribution.
      ...because this is actually a search through many different
      parameter values, and can take quite a while.
  (2) generate the numerical code (fast_ldlt.c, etc) from the code
      generation parameters. this is quite fast.

> what are the build-depends ?
> perl

yes .. needed for fbuild. right now the numerical files shipped with
ODE are optimized for my pentium III. on other platforms you can
often do better by reoptimizing (SGI for instance).

> is it still necessary to use mmap in stack.cpp ?

hmmmmm ... strictly speaking no, but it sure is convenient. the stack
holds joints in a joint group, and the stack may need to be increased
in size without relocating the joints (because other things hold
pointers to them). the mmap stack is an easy way to reserve a large
chunk of address space and only allocate memory as it is needed.
a malloc()/realloc() approach would need to either:
  * preallocate as much as will ever be needed (hard to figure out the
    maximum here, and allocating too much can waste that much memory).
  * or realloc() when necessary and adjust pointer values everywhere -
    more complex and error prone.
the mmap() behavier of mmap in linux can not be relied upon on all
platforms - or even on different versions of linux.

hang on --- just had an idea. if we malloc() a large chunk of mem
(say 100Mb), will mem pages actually be assigned to the allocated
address space? ... or only when they are written to? this is worth
checking. if pages are not assigned until referenced then we can
just malloc() instead of mmap() ... but the behavior may differ on
different OSs. i think this will work in linux but i don't know about
windows or other *nix's.

> if it is still needed I have to write a test for MAP_ANON (irix
> doesn't have it)

i know that it's annoying - better schemes for the stack are most
welcome. i guess the joint group could malloc() joints individually,
but then it is a lot slower to create/tear down a bunch of contacts
each step. perhaps we could do this only on platforms where the
mmap stack is hard to implement?

> anyway Russel wants to centralize the defines in one file

yes please - is should be simpler that way.

> some "problems":
> it seems the directories have to be renamed to ode/ode and
> drawstuff/drawstuff
> (the directory with the source of a library - especially its includes
> must be named in the same way they are installed
> - f.e. if you want to have /usr/include/foo/include.h then you must
> put include.h in a directory foo of your source tree)

i thought i had already done this ... the include files live in
include/package_name/* in the ODE distribution, and would be installed
in /usr/include/package_name/* when installed. the #include directives
in the source refer to "package_name/*", so this should work ...?

> PS: to get autoconf/automake to work on windows i need help - i don't
> have (and want) any windows box.

unless the user is running cygwin i don't think this will work, as the
"configure" program is a unix shell script.

russ.

--
Russell Smith
http://www.q12.org