Bug#457075: Salomé packaging
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é
Reply to: