Hello, On Mon, 2005-07-11 at 02:21 -0400, Faheem Mitha wrote: > On Thu, 7 Jul 2005, Adam C Powell IV wrote: > > > Hello and apologies for the delay, > > > > I'm in the process of packaging PETSc 2.3.0, which I anticipate > > completing by the end of next week. The main reason I didn't get it > > done for sarge was the new configuration system, which was mandated > > starting with 2.2.1... > > > > I'll close this bug when it's done. > > Hi Adam, > > In turn, apologies for the slow response. > > Glad to hear that you will be packaging PETSc 2.3 soon. > > As I wrote earlier, I have been working on packaging PETSc 2.2.1 myself. > In light of that, I have a few comments/questions, which I would like to > share with you. > > Firstly, I was wondering why your package does not using the custom > configuration system (called BuildSystem) that PETSc comes with. If I > understand you correctly, you are planning to switch over to using it.
I've put a lot of time into customizing the bmake system to work with other Debian packages and build on all arches, and BuildSystem came up sometime after the start of the sarge "freeze" process a year ago, so I decided to postpone using it until after sarge. Also, I'm not very familiar with python, so learning a brand new configuration system (as opposed to a standard one like autotools) in a new language and getting it to work properly could take an enormous amount of work. So I've been procrastinating. :-) > A major problem that the shared libraries build by default are not > relocatable. This is because (the developers tell me) the shared libraries > are dependent on some other things called dynamic libraries, and so have > to hardwire the location of these dynamic libraries into the shared > libraries. > > I'm not actually sure why these dynamic libraries are needed. In my build > I worked around this by switching off the build of the dynamic libraries. > This appears to work, but I've been told that the PETSc python binding > depend on these shared libraries being present, I'm not sure why. I don't understand what they mean by "dynamic" libraries either. I believe this is their mechanism for runtime loading of libraries as needed, without the requirement of linking all needed libraries to the binary. I can see how this might be helpful for python, but for C(++), the needed libraries are pretty clear at compile time. So I've ignored this. (Also, didn't know that PETSc 2.x has python bindings...) > A possibility would be to do another run and just generate dynamic > libraries, and add these in, but this seems like an ugly kludge. > > I was just wondering how you plan to handle this. > > There also seems to be a problem with the 'make clean' target, as you > already remark in the rules file, in that it does not completely clean the > build tree. Are you planning to point this out to the developers? I think > that would be a good idea. Maybe at some point, when I get some time. :-) > At the moment it seems possible that I will be using DOLFIN > (www.fenics.org/dolfin) in my work. If this happens, I will be building > (and possibily maintaining) Debian packages for DOLFIN, and possibly for > some of the other associated libraries. In that event, I might need your > help in having these packages build against PETSc. This may not be so > easy, since some things about PETSc are non-standard. I hope that is cool. You mean, since some things about the Debian PETSc package are non-standard? I'm glad to help, once I can get petsc 2.3 in. As a first step, I uploaded the revised mpich packages last week. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
