Hello and apologies for the long delay (I've been out of the country for the better part of a month),
On Fri, 2005-07-15 at 21:38 -0400, Faheem Mitha wrote: > > On Mon, 11 Jul 2005, Adam C Powell IV wrote: > > > 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. :-) > > It may be helpful to you to take a look at my very primitive (and large) > package. Perhaps you could also give me tips on improving them. You can > find it at > > deb http://aurora.dulci.biostat.duke.edu/~faheem/debian/ ./ > deb-src http://aurora.dulci.biostat.duke.edu/~faheem/debian/ ./ > > apt-get source petsc > apt-get install libpetsc > > It uses BuildSystem. > > BTW, note that BuildSystem has problems with your build dependencies. > > Specifically, all the atlas3 stuff which satisfies libblas-3.so and > liblapack-3.so does not seem to satisfy BuildSystem's requirement for > blas/lapack. > > BTW, there does not seem to be any record of cxml. Indeed, that's what I've been afraid of: customizing BuildSystem to fit Debian's package system seems a lot harder than customizing the old bmake system, or autoconf/automake/libtool for that matter. > > 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...) > > When you say you've ignored this, do you mean that you have switched > off the dynamic libraies, "dynamic=0", or something else? > > One clearly has to do something, since the default way of making the > libraries causes problems if you move them. I get rid of the rpath, so moving them causes no problems. (rpath also violates Debian policy.) > >> 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. > > No I meant that PETSc itself is non-standard. I assume the Debian > package will be as standard as possible, given that. :-) > > Faheem. Indeed. Thanks for your understanding. :-) I'll have some time next Tuesday to work on this, and hope to be able to upload packages at that time. Thanks, ACP -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]
