Re: Salomé packaging
Hi Adam,
I am André Espaze, the Logilab's employee supposed to help you in the
Salomé packaging for Debian. First I wanted to thank you for the great
work that you did on the current package. Then I would like to let you
know my progress on the testing part.
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.
- it lacks the omniorb4-nameserver package in the dependency list
else the KERNEL component does not find the omniNames command.
- 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.
- 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.
- the GEOM module crashes when trying to add a geometrical object
You can find all the steps that I did, more details and also more problems
at: http://www.python-science.org/ticket/1383
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?
I am looking forward to work with you,
André
On Tue, Jan 26, 2010 at 10:22:12AM -0500, Adam C Powell IV wrote:
> Sorry, forgot to mention a couple of things yesterday. First, the
> package doesn't build in current unstable, because HDF5 transitioned and
> MED didn't transition with it. I may be able to help with MED to
> resolve this, but not until next week. (It builds fine in my unstable
> chroot updated a few days ago, but that machine doesn't have enough disk
> space to build the whole thing.)
>
> On Mon, 2010-01-25 at 11:45 -0500, Adam C Powell IV wrote:
> > Now for one problem. The VISU module doesn't completely compile,
> > because of a symbol/prototype incompatibility within its CONVERTER
> > library. I don't know quite enough C++ to fix this, can someone help?
>
> Second, the log with this build failure is in
> http://lyre.mit.edu/~powell/salome/salome_5.1.3-3_amd64.build - search
> for *** . The relevant files are
> VISU_SRC_5.1.3/src/CONVERTOR/VISU_MergeFilterUtilities.cxx and .hxx. I
> don't understand why TGetFieldData in the prototype with the vtkDataSet*
> argument works for both TGetPointData and TGetCellData but the one with
> the VISU::TFieldList* argument doesn't...
>
> -Adam
> --
> GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
>
> Engineering consulting with open source tools
> http://www.opennovation.com/
Reply to: