[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: