[petsc-dev] builder.py issues

[Matthew Knepley]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100314/acd3466c/attachment.html>