[petsc-dev] builder.py issues

[Matthew Knepley]

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>