Hello Andre, No problem regarding the reply time. It takes a while to come up to speed on git, quilt, and the complicated Debian packaging system. I've made a lot of progress in getting salome to build and clean itself properly, so some things should be much easier. The only thing not building properly at this point is VISU, there's a C++ problem mentioned earlier which I don't know how to resolve. On Wed, 2010-02-17 at 11:37 +0100, Andre Espaze wrote: > 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. Good point. I have just made that change, thanks. > Anyway I would like to discuss > the configure step in the following ticket: > http://www.python-science.org/ticket/1405 You make a good point about different features needed for different modules. But I think the loop is helpful because it is easy to change or fix variables which apply to all of the modules, and cuts down on the size of the rules file. It needs to do the documentation separately for each module because not all modules have documentation; I'd like to keep from having to do that in the configure-stamp target. That said, if you can produce a patch which does this without making things too long (for example by having a COMMON_CONFIGURE_OPTIONS makefile variable for options needed by all modules), I will likely adopt it. [Skipping resolved issues...] > > 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. Great, let's see how we can make the other modules work... > > > 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. Sounds good. Thanks for your help! -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