Hello André, Thanks for your work on this, I'm glad it's working. I'm afraid I won't have much time to look into your tree, let alone merge the differences, for a few days, but will get back to you soon.
-Adam On Mon, 2010-05-17 at 12:06 +0200, Andre Espaze wrote: > Hi Adam, > > Sorry for the lack of news, I was focus on making VISU work. I have > succeeded to build a Salome package however the current result is > unfortunately split from our development line. That's why I will first > explain my steps and then ask your advice on the merge as I saw that > serious reorganizations are also pending. > > My goal is to provide a functional Salome package for mechanical > engineering even if incomplete. As a consequence the necessary modules > are for me KERNEL, GUI, GEOM, MED, SMESH and VISU. As VISU was failing > in the build process of debian/rules, I decided to build it by hand by > exporting the necessary environment variables. In that case I only had > to modify the gui-build-in-tree.patch (attached to the mail) for making > the libVISU linking work by adding the path to libToolsGUI. > However, back to the complete debian/rules process, the compilation > was still failing in the VISU CONVERTER library because of an absent > template symbol (probably the same problem described in your mail on > the 25th of January). So I needed to investigate the configure and > build steps of debian/rules but those steps take lot of time. For > easing my researchs, I decided to work on a package building > only the necessary modules which I called salome-core. The working > snapshot is available here: > http://www.python-science.org/files/salome-core.tar.gz > and I have attached the resulting debian/rules which configure > every module separately. I could not find the problem in the > previous loop configuration. > > >From there two questions arise. First, I like the debian/rules file > of salome-core but I remember that you were against such solution for > maintenance reasons. Would you like me to adapt it as a loop or did you > finally change your mind? From now it seems anyway that VISU needs to be > configured separately. Second, could the current salome-core package be > a starting point for the reorganizations that we discussed previously? > For me it has the main advantage to build only the necessary modules, > thus saving time for every run of Salome packaging. However it will > require to write several packages (salome-advance and salome-dev). > By comparing to the opencascade package, I understand that the whole > building should be made in a row and the subpackages splitted by > several *.install files. > > ... > > > > > - self.CMD=['SALOME_ContainerPy.py','FactoryServerPy'] > + self.CMD=['SALOME_Container','FactoryServerPy'] > (I have adapted the patch to the current version.) > ... > > I just took care of this, the result is in the alioth git repository. > Thank you for the update. Even if the current version work, I would > prefer to rename 'SALOME_ContainerPy.py' to 'SALOME_ContainerPy' because > '/usr/bin/SALOME_Container' already exists and is finally overwritten in > the install step of debian/rules. > > Even if several points still need to be discussed or adapted, the > good point is that we know now how to build a Salome package with the > essential modules. Once again, thank you very much for all your efforts. > I am going to track the remaining bugs at runtime (some menu do not show > up in SMESH, the results can not be seen in VISU). > > All the best, > > André -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
