yade-dev team mailing list archive

[Václav Šmilauer <eudoxos@xxxxxxxx>]

[Sending cc of this first yade-pkg message to yade-dev so that people
interested can subscribe]

Hi packagers!

Maintaining building and packaging process is a tedious task that is not
very visible. Thank you for being so brave to take part in it. Below, I try
to suggest what could be our goals in near future.

Generally, I have four things in mind: 1. ease development with a
ready-made IDE configuration 2. create packages for linuxes besides ubuntu
3. port to windows 4. simplify and enhance the build system. Details
follow.

----

1. Pick one or several good IDE for Linux (kdevelop, geany, eclipse...?)
and make developing yade in it as simple as possible. I saw many people in
Oxford use gedit and navigate source files in nautilus, which is as
inefficient as it might get. Which of those are you familiar with? (I use
gvim, but that is not the choice we want to force on peoples). There are
some scattered information on the wiki, but I was not able to follow those
with kdevelop4 (it says, for instance, that yade is not recognized as
executable, but that is because it is a python script and python must be
the first argument)

What it should include is: navigating source by tags, showing class
definitions/declarations, automatically follow code style, run compilation
from the IDE for release/debug version, support gdb for stepping through
the program. Optionally, it should also integrate with bzr for commits,
logs, diffs etc.

As far as I know, eclipse is very flexible in all those aspects, but it is
a huge piece of software and I am not sure that we manage to tame it.
KDevelop seems to be too KDE-centric, geany is simplistic in some aspects,
though I did not really look at it much.


2. Create proper rpm packages (for opensuse and fedora), have them built
perhaps via opensuse build service, once we get familiar with that. Having
no packages, future talented developers can be scared by the complexity of
the installation. 


3. Port to windows. I am sorry to say that, but I keep running in people
who will not install Yade because they do not run Linux. It would be
possible (using some scripting and essentially compiling all dependent libs
from sources) to cross-compile all that using gcc-mingw32 cross-compiler (I
used to compile a wxWidgets-based program like that in the past, though it
was much smaller). I asked at a linux server about possibilities on that,
but so far I got no definitive response
(http://www.abclinuxu.cz/poradna/programovani/show/316236). Another
possibility is to use msvc, which might be easier, but I really have no
idea. Two prerequisities would be:

3a. Identify clearly what gcc extensions we use, find out how to achieve
the same with other compilers (msvc, icc): __attribute__() vs. __declspec
and so on.

3b. Identify which parts of the code are not cross-platform. At a few
places, POSIX-specific functions are used (nanosleep, dlopen), find out how
to make them compile on other platforms as well.


4. Simplify the build system: currently, scons logic is scattered in a few
files. It would be better to have one yade-specific script that would
figure out what to compile (how to put plugins together depending on
features, what they depend on etc); then, a yade-agnostic tool like scons
would be used to resolve dependencies, run the compiler etc. Notably,
porting to other platforms (windows) would be easier.

4a. we might want to get rid of header installation (which puts
pkg/dem/directory1/directory2/header.hpp to yade/pkg-dem/header.hpp), but I
have no clear idea how to make it happen properly. I don't want much to
change #include paths, since they are readable (for me at least), putting
all fiiles straight under pkg/dem without further structure would be too
messy (or maybe not that much if tags are used?) and having .cpp files in
the structure and .hpp in pkg/dem directly would be quite messy as well.
OTOH, we clearly want to avoid typing
#include<yade/pkg/dem/Engine/GlobalEngine/NewtonIntegrator.hpp> and such.

4b. if the logic is separate from scons, we might easily try other build
systems, especially if targetting windows.

4c. I have script to compile _all_ files (including plugins, python
modules etc) all at once and then just symlink the rest. That has one bad
effect, i.e. that lots of RAM is neee for the compilation, and a few good
ones: (a) plugins don't have to be linked to other plugins, since they are
all in the same file (b) installation size is dramatically reduced, to
about 5MB, since all template instantiations etc are common (c) we wouldn't
have to dlopen plugins with RTLD_GLOBAL (which we have to do); that is the
reason why importing scipy crashes yade currently (just like it used to
crash with lsm.gengeo, which was worked-around dirrefently). The negative
effect of RAM consumption can be alleviated by compiling chunk-by-chunk
anyway, so I think this is the way for the future.

4d. Support compilation with llvm/clang out-of-the-box. It is faster,
takes less RAM. Clang is more strict in following the c++ standard; we need
to test which version of qt4 will compile with clang (the one in lucid will
not, but the one in maverick might). Although OpenMP is not supported, that
is mostly fine for developing debugging. Clang supports all gcc extensions
we use, no changes to our code are necessary.

----

I would like to open discussion about relevancy of each of the goals
outlined. If you have some other possibilities in mind, do not hesitate to
share those. Once there is some agreement, we can start creating
blueprints, splitting them in smaller parts and tracking them.

Thanks for your ideas and cooperation. Cheers!

Vaclav