Hello again,
I now have 10 modules enabled, and have made all but one of the patches
upstream-friendly, though I've only uploaded the -3 source package to
http://lyre.mit.edu/~powell/salome/ at the moment.
Nicolas, can you do me a favor and try to push some of the patches
upstream? You can find them in the salome_5.1.3-3.debian.tar.gz file,
in the debian/patches directory; I can send them to you individually if
you prefer. The patches fall into in several categories, and are
separated out by module:
* *-safe-include: Eliminate extern "C" blocks where they are
unnecessary -- and even harmful, as they break building with
OpenMPI. See the patch head for details.
* *-cleanup: Fixes for compiler bugs which break the build with
recent compilers.
* *-hdf5-needs-mpi: The HDF5 header and library files need MPI in
order to work, so this includes the MPI -I and -L flags in with
those of HDF5, and puts MPI checks before HDF5 ones.
* *-mpich-mpi: Replace MPICH checks with MPI checks, as I've made
it compatible with OpenMPI.
* *-use-gui-check: Use check_GUI.m4 in the GUI module directory,
instead of the rewritten version of that file in several other
module directories.
* *-build-in-tree: Debian requires that the whole package build
first, then install. These patches make this possible.
These patches will not only make it easier to maintain the package, but
will assist anyone building Salomé on Debian/Ubuntu in the future. And
all of them should preserve the ability to build as before, let me know
if that is not the case.
Other specific patches:
* kernel-remove-mpi-undefs: Not sure why these undefs are there,
they break OpenMPI compatibility.
* kernel-occ-includes: Search for OpenCASCADE header files both in
the default location when building OCC from source and also in
the Debian/Ubuntu package location.
* hxx2solame-destdir: Use DESTDIR for install.
* med-scotch: Search for Scotch files both in the default location
when building Scotch from source and also in the Debian/Ubuntu
package location.
* med-missing-libs: Add the MED libraries to the mprint_version
link command.
* visu-flags-typo: Fix incorrect automake flags variable.
* kernel-mpi-libs: This is the one which should *not* go upstream,
as it tests for the Debian-specific MPI alternative symlink lib
names.
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?
Before upload, I think this needs a few more modules, a full copyright
audit, and at least a working GUI shell. I've only done the audit for
the first two modules (KERNEL and HXX2SALOME), and haven't tried running
the shell yet...
Cheers,
Adam
On Sun, 2010-01-10 at 17:53 -0500, Adam C Powell IV wrote:
> On Sun, 2010-01-10 at 23:28 +0100, Nicolas Chauvat wrote:
> > Hi,
> >
> > As part of the OpenHPC project[1], Logilab commited itself to package
> > Salomé for Debian. We had seen the great work you have done and are
> > glad that you are resuming it.
>
> Wow, thank you for this terrific news! Have you started to forward-port
> the old patches to a new package, or are you using a different approach?
>
> A correction: most of my work on this was two years ago, not three.
>
> > André Espaze has been developing a connector between Salomé and
> > Code_Aster for the past few months. He is about to continue his work
> > with the packaging of Salomé. He will have the help of Pierre-Yves
> > David. We also have a Debian developer on the team, Alexandre Fayolle,
> > but he will not have a lot of time for this particular project in the
> > upcoming months.
>
> Okay. Let me know how I can best fit in with your plans for this
> project.
>
> > I am cc'ing every person involved to make sure everyone can get in
> > touch easily. Is debian-science the best place to discuss this topic
> > or should we take the discussion off-list?
>
> I think this list is pretty good as long as we are talking about
> generalities, as I think some of the people on the list will have good
> suggestions. When we start to get into the details of patches and the
> package, maybe it will make sense to go off-list.
>
> > Hopefully, the fact that we have been working with upstream for years
> > will help us get this work done more easily.
>
> This is terrific. My patches are Debian-specific, and need some work to
> make them fit the needs of both upstream and Debian. This gives me hope
> that doing that work will help to actually get the patches into the
> upstream source!
>
> This is the best news I've heard in a long time. Thanks again, I look
> forward to working with you.
>
> Regards,
> Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part