[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 _______________________________________________ Mailing list: https://launchpad.net/~yade-pkg Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-pkg More help : https://help.launchpad.net/ListHelp
