[petsc-dev] moab nightlybuild failure

[Barry Smith]

  I think you guys are over-complicating things with so many (unneeded?) combinations of possibilities.

  Is the following a good simplifying rule?

  PETSc obtained with git uses moab (by default the master branch) obtained with git. PETSc obtained with tar balls uses moab obtained with tar balls. 

    I propose that we keep petsc master in sync with moab master so the default behavior is just like the tar balls. Now if someone is working on either a PETSc branch or a moab branch that will affect the other package they will have two branches (one in PETSc, one in MOAB) they keep in sync. If someone else wants to try out they stuff that is being developed they manually checkout the corresponding branches in each package and then run configure. For example I would have in PETSc the branch barry/cool-new-moab-feature-for-petsc and in moab the branch barry/cool-new-moab-feature-for-petsc I don't think it is worth having complicated branch aware code in BuildSystem to always get the right the moab branch depending on the petsc branch since not many people will use it.

   This could be extended a bit by the gitcommit value in moab.py which means don't use moab master by default. But I think this could be dangerous to ever use since there is only one value, it is not per branch of PETSc-dev, so better to keep the simple model of petsc master uses moab master.

   Barry





On Jun 28, 2013, at 2:06 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> 
>> sure - hence my assertion that similar functionality could be
>> imlemented with tarballs [with the caveal of using unique urls]
> 
> The difference is that you have to cache the URL that was unpacked into
> the (global) externalpackages.  Consider that the user could have built
> with a different PETSC_ARCH in between.  I suppose this could be done by
> writing a hidden .downloadurl file into the package directory after
> unpacking.