I do not propose to remove the possibility for the user to type
"configure" and "make" separately, if they really want to. Just add a
new possibility to do everything at once, like what you apparently
describe by TOPSInstaller. You should keep a non-gui version of it, too,
for remote installs.

On 06/21/2011 01:50 PM, Barry Smith wrote:
> 
> Run ./bin/TOPSInstaller.py     -- the next generation of this should be a 
> javascript  gui beasty that runs in your browser.
> 
> 
> Regarding the ./configure; make  model. If we didn't have this all the 
> gnu/linux bigots would give us a hard time (which they do already). In other 
> words, it is what most people expect. 
> 
>    Barry
> 
> On Jun 21, 2011, at 1:46 PM, Andrew Knyazev wrote:
> 
>> On 06/21/2011 01:29 PM, Barry Smith wrote:
>>>
>>> On Jun 21, 2011, at 1:07 PM, Andrew Knyazev wrote:
>>>
>>>> On 06/21/2011 12:24 PM, Jose E. Roman wrote:
>>>>>> SLEPc has the headers not in the same directory as PETSc? Why?
>>>>> SLEPc could be installed by a user that does not have write permission in 
>>>>> PETSc's directory.
>>>>
>>>> PETSc gives so many different configure options, so it is quite rare to
>>>> see it installed by a sysadmin nowadays, in my experience.
>>>>
>>>> At any rate, it would be nice to have a tighter integration of SLEPc
>>>> into PETsc, ideally, simply to be able to install SLEPSc by using
>>>> --download-slepsc=1 option in PETSc. I am sure that it would
>>>> significanly increase the number of SLPEc users.
>>>
>>>
>>>  To do this we need to broaden our Packages concept to have both pre and 
>>> post packages. Currently we handle pre packages (that PETSc uses) pretty 
>>> well but do not handle post packages (that use PETSc). Prometheus is this 
>>> weird thing that is partially pre and partially post and is handled a bit 
>>> too ad hocly.
>>>
>>>  In some ways post packages are pretty easy, we just need to set up the 
>>> infrastructure. 
>>>
>>>  Since the user doesn't care about pre and post we'd want to support the 
>>> same --download-xxx syntax in both cases (with some way of passing optional 
>>> arguments) and, of course, as Jed points out additional -download-xxx can 
>>> be used after a build.
>>>
>>>   Barry
>>
>>
>> For the user, could you perhaps add a new script "install" which would
>> just do everything: configure, make PETSc, install PETSc, and all
>> necessary pre and post packages, plus compile all examples? I could
>> never understand why PETSc requires the user to type "make" separately
>> and then also compile every individual example.
>>
>> Of course, typing "make" gives the user a false feeling that they know
>> and control what they are doing. But this feeling goes away quickly, and
>> the moral value of these few high moments is not that great anyway.
> 


Reply via email to