Hi Satish, Thanks very much for your help with my dumb BuildSystem question.
I have tested my changes to PLAPACKR32-hg and pushed my changeset back to the repo. (I just fixed some missing function prototypes, one of which was causing problems on 64-bit systems for me.) Can you please update the tarball on the FTP site? Thanks, Richard On 11/7/2011 3:26 PM, Satish Balay wrote: > On Mon, 7 Nov 2011, Richard Tran Mills wrote: > >> Hi Folks, >> >> I am trying to test the changes I have made to the PLAPACKR32-hg package >> before pushing them back up and asking Satish to rebuild the tarball. I >> guessed that I could do this by deleting >> $PETSC_DIR/externalpackages/PLAPACKR32-hg and >> $PETSC_DIR/$PETSC_ARCH/lib/libPLAPACK.a, pointing the download path to my >> local tarball, and running configure again. I get the following: > >> Now, my question is: Why does BuildSystem think that it doesn't have to >> rebuild PLAPACK? I have deleted >> /home/rmills/proj/petsc-dev/ubuntu-gnu_g/lib/libPLAPACK.a. Configure tries >> to >> link with that, anyway, and then eventually gives up and tells me that the >> downloaded PLAPACK can't be used. Shouldn't it *not* do that since this file >> doesn't exist? > do: rm -f /home/rmills/proj/petsc-dev/ubuntu-gnu_g/conf/PLAPACK > > configure creates a config file for each pakage - and stashes it at > this location. If configure is reinvoked - it checks the previously > created conf file [i.e > /home/rmills/proj/petsc-dev/ubuntu-gnu_g/conf/PLAPACK] and sees if it > matches the currently generated one [to see if all compiler, mpi etc > options are the same]. If they match - it decides not to rebuild that > package. > > Satish > > >> I can work around this by deleting my $PETSC_DIR/$PETSC_ARCH directory and >> rebuilding everything, but this can take a long time if I have a lot of >> downloaded packages. >> >> --Richard >> >> >>
