<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 25, 2018 at 1:55 PM, Smith, Barry F. <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Feb 25, 2018, at 12:16 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
> "Smith, Barry F." <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
><br>
>> So fix the damn script instead of just bitching about it! Jeepers, that is what open source is all about.<br>
><br>
> Yes, my last email was lazy. But your criticism of Lisandro fixing it<br>
> in his packaging script (which he can just do without explaining to<br>
> anyone, and doesn't have to wait for a release) is much the same.<br>
><br>
>> Or if it is so terrible and unfixable then write a new script. The<br>
>> time wasted on mailing lists and arguing with package manager<br>
>> developers would be better spent fixing installer code.<br>
><br>
> Agreed. I think this would all be cleaner with a canonical, supported<br>
> way of querying whether a feature is enabled. Right now we have<br>
> RDict.db (from within a Python script, but it takes a lot of work),<br>
> lib/petsc/conf/petscvariables from a makefile, and include/petscconf.h<br>
> from C source, all with different syntax.<br>
<br>
Each of these is suppose to serve its own purpose.<br>
<br>
The RDict.db is from within configure, the petscvariables is from from within makefiles, and the petscconf.h is from within source code.<br>
<br>
The model used to be ok until the test harness (and maybe the new gnumake test system) needed information that is not provided in petscvariables.<br>
<br>
I think the correct fix is not to get rid of the three data sets but to make sure that each data set has everything needed for that mode of usage. So petscvariables should contain everything needed by the makefiles so the makefiles don't need to try to get information from a different source. In fact isn't this the only problem? Isn't it relatively easily fixable by putting more info in the the petscvariables and then any horrible code that tries to get the information for makefile from petscconf.h can be removed?<br>
<br>
What do you propose?<br>
<br>
<br>
<br>
><br>
> It would be a lot less code to write the install directly in the<br>
> makefile, and would get permissions correct by using the 'install'<br>
> command.<br>
<br>
Anyone is free to write the installer in make if they like. It use to be in make but we found it too hard to maintain so switched to using python a long time ago. (This was before gnumake).<br>
<br>
I find all the gnumake code you have contributed to PETSc completely incomprehensible and hence impossible to maintain which is why I prefer the easily understood python installer (that yes it definitely does need work).<br></blockquote><div><br></div><div>I have written a description of Jed's gnumake here</div><div><br></div><div> <a href="https://www.cse.buffalo.edu/~knepley/classes/caam519/CSBook.pdf">https://www.cse.buffalo.edu/~knepley/classes/caam519/CSBook.pdf</a></div><div><br></div><div>in Section 1.3.5</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Barry<br>
<br>
<br>
><br>
> I don't think examples should be installed by default.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>