Pushed a fix. Matt
On Sun, Mar 14, 2010 at 5:55 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Matt, > > You have a bug in here. Generating that file petscmachineinfo.h assumes > you have a Fortran compiler configured See attached configure.log > > Sorry for being lazy and not fixing it myself. > > > Thanks > > Barry > > On Mar 14, 2010, at 1:06 PM, Matthew Knepley wrote: > > I pushed a fix for generating petscmachineinfo.h from Configure. However, I > was unable to > trace some of the nake vars used back to Python. I left them unexpanded in > the output. > > Satish, can you take a look? I am about to test now. > > Thanks, > > Matt > > On Wed, Mar 10, 2010 at 4:38 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > >> >> On Mar 10, 2010, at 3:26 PM, Matthew Knepley wrote: >> >> I would advocate a separate section. It might make sense to introduce >> dependencies >> here. This is what always ends up making build systems hellishly >> complicated, but >> it is also necessary I think. Maybe we can do something very simple. >> >> I am envisioning dependencies not among files, which I think is >> complicated and leads >> to bad programming, but dependencies between whole operations. That way we >> can >> say "building module ksp" depends on "building module mat". We can use >> Python >> objects, and override __call__, and then build a DAG of objects, which >> executes. This >> is very similar to configure, and I think it works well there. >> >> It would not be hard to put what we have in this format. It just involved >> gathering up >> the current calls into objects, which would prob look nicer, and ignoring >> dependencies. >> >> >> "Modules" in PETSc are currently organized by filesystem directories. >> sys -> libpetscsys vec -> libpetscvec etc. >> >> 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: >> >> Each directory has a file (say 'dependencies" ) that lists all the >> other directories at that level that it depends on. >> Each directory has a directory (say 'dependencies') that has soft links >> in it for each other directory it depends on. >> Other ? >> >> The "walking tool" would then march through the directories building up >> this information into python objects. >> >> Barry >> >> >> >> >> Matt >> >> On Wed, Mar 10, 2010 at 3:14 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >> >>> >>> 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. >>> >>> 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. >>> >>> Barry >>> >>> On Mar 10, 2010, at 3:10 PM, Matthew Knepley wrote: >>> >>> On Tue, Mar 9, 2010 at 8:48 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >>> >>>> >>>> 1) petscmachineinfo.h is generated by THE MAKEFILE, what were we >>>> thinking. This needs to be changed to be generated by configure >>>> >>> >>> I can fix >>> >>> >>>> 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. >>> >>> >>> Where is the code that does it now? >>> >>> Matt >>> >>> >>>> >>>> Barry >>>> >>>> >>> >>> >>> -- >>> What most experimenters take for granted before they begin their >>> experiments is infinitely more interesting than any results to which their >>> experiments lead. >>> -- Norbert Wiener >>> >>> >>> >> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which their >> experiments lead. >> -- Norbert Wiener >> >> >> > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100314/d1d09a53/attachment.html>
