Pushed a fix.<div><br></div><div> Matt<br><br><div class="gmail_quote">On Sun, Mar 14, 2010 at 5:55 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><br></div> Matt,<div><br></div><div> You have a bug in here. Generating that file petscmachineinfo.h assumes you have a Fortran compiler configured See attached configure.log</div>
<div><br></div><div> Sorry for being lazy and not fixing it myself.</div><div><br></div><div><br></div><div> Thanks</div><div><br></div><font color="#888888"><div> Barry</div></font><div><div></div><div class="h5"><div>
<br><div><div>On Mar 14, 2010, at 1:06 PM, Matthew Knepley wrote:</div><br><blockquote type="cite">I pushed a fix for generating petscmachineinfo.h from Configure. However, I was unable to<div>trace some of the nake vars used back to Python. I left them unexpanded in the output.</div>
<div><br></div><div>Satish, can you take a look? I am about to test now.</div> <div><br></div><div> Thanks,</div><div><br></div><div> Matt<br><br><div class="gmail_quote">On Wed, Mar 10, 2010 at 4:38 PM, Barry Smith <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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Mar 10, 2010, at 3:26 PM, Matthew Knepley wrote:</div> <br><blockquote type="cite">
I would advocate a separate section. It might make sense to introduce dependencies<div>here. This is what always ends up making build systems hellishly complicated, but</div><div>it is also necessary I think. Maybe we can do something very simple.</div>
<div><br></div><div>I am envisioning dependencies not among files, which I think is complicated and leads</div><div>to bad programming, but dependencies between whole operations. That way we can</div><div>say "building module ksp" depends on "building module mat". We can use Python</div>
<div>objects, and override __call__, and then build a DAG of objects, which executes. This</div><div>is very similar to configure, and I think it works well there.</div><div><br></div><div>It would not be hard to put what we have in this format. It just involved gathering up</div>
<div>the current calls into objects, which would prob look nicer, and ignoring dependencies.</div></blockquote><div><br></div></div> "Modules" in PETSc are currently organized by filesystem directories. sys -> libpetscsys vec -> libpetscvec etc. </div>
<div><br></div><div> I hate to introduce "yet another" way of introducing relationships between "modules" that stores the information in some other way. Since we are using the filesystem for this information I'd like to keep it that way and thus keep the extensibility. Some possibilities:</div>
<div><br></div><div> Each directory has a file (say 'dependencies" ) that lists all the other directories at that level that it depends on. </div><div> Each directory has a directory (say 'dependencies') that has soft links in it for each other directory it depends on.</div>
<div> Other ?</div><div><br></div><div> The "walking tool" would then march through the directories building up this information into python objects.</div><div><br></div><font color="#888888"><div> Barry</div>
</font><div><div><br></div><div><br></div><div><br><blockquote type="cite"><div><br></div><div> Matt<br><br><div class="gmail_quote">On Wed, Mar 10, 2010 at 3:14 PM, Barry Smith <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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div> Make marches through the directories in the order of DIRS listed in each makefile. Thus make recursively goes in the correct order because it does not simply walk the tree but instead walks the tree given in the order in the makefiles. Note: I don't really like this current design, that is I don't like the directories being listed in the makefile and then walked through in that order. I prefer that it get the information about the directories directly from the file system. <div>
<br></div><div> So I do not have a good solution to this problem. Perhaps builder.py has to have a seperated section specifically for building the modules.</div><div><br></div><font color="#888888"><div> Barry</div></font><div>
<div></div><div><div><br><div><div>On Mar 10, 2010, at 3:10 PM, Matthew Knepley wrote:</div><br><blockquote type="cite">On Tue, Mar 9, 2010 at 8:48 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> 1) petscmachineinfo.h is generated by THE MAKEFILE, what were we thinking. This needs to be changed to be generated by configure<br>
</blockquote><div><br></div><div>I can fix</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 2) the Fortran module files must be generated in a certain order, builder.py has no concept of going in a particular order, not sure how to fix this.</blockquote>
<div><br></div><div>Where is the code that does it now?</div> <div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font color="#888888"><br>
Barry<br> <br> </font></blockquote></div><br><br clear="all"><br>-- <br>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<br> </blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>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<br> </div></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>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<br> </div></blockquote></div></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>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<br>
</div>