[petsc-dev] moab nightlybuild failure

[Satish Balay]

yes - the patch I posted check for 'autoreconf' - and if it exists -
only then the 'git clone' is used.

and then it runs 'autoreconf' before attempting to run configure.

Satish


On Thu, 27 Jun 2013, Timothy J. Tautges wrote:

> Sounds good. Running a script to call autoreconf would be no easier than eunning autoreconf. 
> 
> 
> - tim 
> 
> (Sent from an Androd that dosnt autocorect as wel as an ipone) 
> 
> -------- Original message --------
> Subject: Re: [petsc-dev] moab nightlybuild failure 
> From: Barry Smith <bsmith at mcs.anl.gov> 
> To: "Timothy J. Tautges" <tautges at mcs.anl.gov> 
> CC: petsc-dev at mcs.anl.gov,jedbrown at mcs.anl.gov 
> 
> 
> On Jun 27, 2013, at 8:46 PM, "Timothy J. Tautges" <tautges at mcs.anl.gov> wrote:
> 
> > I've been mulling whether by default petsc should point to a release tarball anyway, I think it should (4.6 being the latest).
> 
>   PETSc releases should point to moab releases. But PETSc-dev should point to moab-dev
> 
> > 
> > Any time you grab directly from git you can expect to have to run autoreconf, since by policy we don't store configure file in the report.
> 
>    Do you have scripts/tools to run the "autoreconf" easily that we can call?
> 
>    Barry
>  
> > 
> > 
> > - tim 
> > 
> > (Sent from an Androd that dosnt autocorect as wel as an ipone) 
> > 
> > 
> > 
> > -------- Original message --------
> > Subject: Re: [petsc-dev] moab nightlybuild failure 
> > From: Satish Balay <balay at mcs.anl.gov> 
> > To: Jed Brown <jedbrown at mcs.anl.gov> 
> > CC: petsc-dev at mcs.anl.gov,tautges at mcs.anl.gov 
> > 
> > 
> > 
> > On Thu, 27 Jun 2013, Jed Brown wrote: > Satish Balay writes: > > > Ok - fixed in 'balay/fix-moab-git'. Any comments? > > > > https://bitbucket.org/petsc/petsc/commits/1f16e75d68ca70d003ea3ef4dde0f67dcfe822d6 > > Looks okay. What is the recommended way to _not_ try to use the Git > version? Pass the URL directly? The current code is a bit of mess. For one - I don't know why the GNUPackage requires URLs to be split up as such: >>>>> self.downloadpath = 'http://ftp.mcs.anl.gov/pub/fathom/' self.downloadname = 'moab' self.downloadfilename = 'moab' self.downloadversion = 'nightly' self.downloadext = 'tar.gz' <<<< But ignoring this we currently have stuff like the following - where the urls are attempted in the sequence specified. If the first one fails - try the next one: >>>>> self.download = ['https://elemental.googlecode.com/files/elemental-0.79-p1.tgz', 'http://ftp.mcs.anl.gov/pub/petsc/externalpackages/elemental-0.79-p1.tgz'] <<<<<< with [potential support] for multiple p
 rotocols. - as retrieval.py lists: [we also support urls of type file://path] >>> # Fix parsing for nonstandard schemes urlparse.uses_netloc.extend(['bk', 'ssh', 'svn']) <<<< And currently this default can be overwriten by user with: --download-package=url In this context we should not have a separate stuff for git [self.giturls/self.gitcommit]. It should be rolled into the above common url notation. [note: the current git code ignores user specified --download-package=url - and just goes ahead and does the git stuff specified in package.py] Somehow we have to add in 'prereqisites' to the 'repo' type urls in the above scheme. And then perhaps retrieval.py can be asked to ignore repo-urls with some option like '--url-git=no' Also - the repo urls need better support wrt: 'getting updates & rebuilding package'. Current code for this is tarball centric [with some bad behavior - like not detecting a changed url etc..] Satish
> 
>