[petsc-dev] moab nightlybuild failure

[Vijay S. Mahadevan]

The current Cmake build system is broken in MOAB and perhaps setting
that right might give an alternative way to configure things if petsc
is cmake-enabled. I will take a look at it this weekend.

Moab releases do have a configure script and only moab-dev needs autoreconf.

Vijay

On Thu, Jun 27, 2013 at 10:17 PM, Timothy J. Tautges
<tautges at mcs.anl.gov> 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" 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 > To: Jed Brown > 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 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