Hi Adam, Thank you very much for your fast reply. I am sorry for not being as responsive, I am new to Debian packaging and I am also discovering git.
> > I have succeeded to build most of the Salomé modules with the > > version 5.1.3-3 that you uploaded at http://lyre.mit.edu/~powell/salome/ > > however I wanted to discuss the following problems: > > > > - the configure step in 'debian/rules' needs to add VTKSUFFIX="-5.4" > > else vtk is not found and many components do not build. > > Indeed, I built -3 before VTK 5.4 was in unstable. I am using > --with-vtk-version=5.4 which seems to do the same thing. Yes but I have a slight preference for VTKSUFFIX because it avoids such warning in the configure step:: WARNING: unrecognized options: --with-vtk-version when the module does not deal with VTK. Anyway I would like to discuss the configure step in the following ticket: http://www.python-science.org/ticket/1405 > > > - it lacks the omniorb4-nameserver package in the dependency list > > else the KERNEL component does not find the omniNames command. > > Okay, the salome binary package needs to depend on this, right? I don't > think it needs to be in Build-Depends. Yes you are right and I made a mistake. The omniorb4-nameserver is already in debian/control, I did not know the difference between Build-Depends and Depends. > > > - as you said, the med 2.3.5 library needs to be built manually > > with hdf5-1.8.4 but the main problem is that tests do not pass > > in that case. > > There are patches to hdf5 (bug 510057) and med (bug 566828, fix is in > the git repository) to build these two using the default MPI > implementation, e.g. OpenMPI on most arches, LAM on others (soon MPICH2, > which will require further changes to the current HDF5 package...). The > HDF5 team is a bit slow to adopt patches, but hopefully plans for a > March freeze will get this done, so MED-MPI and Salomé can get in. Med is running fine with the build instructions that you provided me off list. Thanks for the informations. > > > - it seems to lack the 'config.h' file in the libopencascade-* > > packages. Else do you know where that file could be? I fear that > > some components (like GEOM) really need it. > > Denis replied to this. I didn't notice any problems building GEOM, are > there run-time issues which could result from missing this file? > > > - the GEOM module crashes when trying to add a geometrical object > > I see. Could this be related to the OCC config.h issue? I don't see > how... In fact I do not say that the problem is related but I just wanted to check the preprocessor definitions in that file and maybe find some clues. I was afraid that upstream use the '-config config.h' gcc option when building Salome, thus potentially introducing custom definitions. When I compiled Salomé for my first time on Debian Lenny, I got a runtime crash of GEOM because of the NO_CXX_EXCEPTION definition used by OpenCascade. I got it in my build process because I had not set my OpenCascade version correctly (see KERNEL_SRC_5.1.3/salome_adm/unix/config_files/check_cas.m4 for the complete story). > > I'm impressed that it actually runs -- hadn't tried to run it yet! Yes, it runs, with very few modules (only KERNEL and GUI from now) but that is already a nice start. > > > How to you plan to collaborate on the package building? I would suggest > > to use the project http://www.python-science.org/project/salome-packaging > > because I can be efficiently organized on such a platform. Would you > > like to add a git or mercurial repository on which we will share the > > package source code? > > It is already on the Debian Science git repository at > http://git.debian.org/git/debian-science/packages/salome.git/ . Thank you, I built Salomé again from that repo. My tickets are there: http://www.python-science.org/project/salome-packaging/0.1 and we can discuss the specific details off list. Cheers, André -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217103708.ga28...@crater.logilab.fr
