[petsc-dev] Stupid BuildSystem question: How do I force rebuild of a downloaded package?

[Richard Tran Mills]

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
>>
>>
>>