[petsc-dev] BuildSystem clean-up

Barry Smith bsmith at mcs.anl.gov
Thu Feb 23 20:01:34 CST 2012


On Feb 23, 2012, at 4:33 PM, Sean Farley wrote:

> So, apparently, BuildSystem creates a working directory for external packages specified with the --download-package option. This seems like a perfect place to do scratch work for the external package but this folder is not cleaned out when the configure options change. Example:
> 
> $ export PETSC_ARCH=arch-test
> $ ./configure --download-metis
> $ ls externalpackages/metis-5.0.2/arch-test/
> FILE1 FILE2 FILE3
> 
> Now, I would expect BuildSystem to clean this directory, at the very least, when options change:
> 
> $ ./configure --download-metis --with-precision=single
> $ ls externalpackages/metis-5.0.2/arch-test/
> FILE1 FILE2 FILE3

   The assumption was that each external package had an appropriate clean that would be called by the XXXX.py BEFORE doing a build to clean it up; this did require each XXXX.py knowing how to call the clean and doing this.  Clearly this assumption was wilding optimistic. 

   The draw back to having buildsystem (note the lack of caps) doing the clean AFTER doing the building is important generated stuff useful for debugging may be lost. So what about doing the clean out of that directory at the beginning, not at the end?

> 
> The same files exist which could spell trouble in this case. Does every package *have* to implement its own clean-up (this sounds crazy!!) or can I safely put this into BuildSystem without the Tower of Babel crumbling around my feet? If this change is "good" then how does BuildSystem determine that the options changed (self.installNeeded?)? Or should it just blow away this directory every time?

   How buildsystem knowns if the package should be rebuilt is NOT stored in that directory so making your change should not affect the current somewhat "smart" build again only if needed logic.

   Barry





More information about the petsc-dev mailing list