<html><body><div>I've been mulling whether by default petsc should point to a release tarball anyway, I think it should (4.6 being the latest).<div><br></div><div>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.<br><br><br><span style="font-size:87%">- tim <br><br>(Sent from an Androd that dosnt autocorect as wel as an ipone) </span> </div><br><br><br>-------- Original message --------<br>Subject: Re: [petsc-dev] moab nightlybuild failure <br>From: Satish Balay <balay@mcs.anl.gov> <br>To: Jed Brown <jedbrown@mcs.anl.gov> <br>CC: petsc-dev@mcs.anl.gov,tautges@mcs.anl.gov <br><br><br></div><br><div>On Thu, 27 Jun 2013, Jed Brown wrote:
> Satish Balay <balay@mcs.anl.gov> 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 protocols. - 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
</div></body></html>