petscvariables: hardwired build dir instead of install dir

[Barry Smith]

On Mar 24, 2008, at 11:26 PM, Matthew Knepley wrote:
> On Mon, Mar 24, 2008 at 10:53 PM, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>>
>>
>> On Mar 24, 2008, at 10:42 PM, Matthew Knepley wrote:
>>> On Mon, Mar 24, 2008 at 10:38 PM, Barry Smith <bsmith at mcs.anl.gov>
>>> wrote:
>>>>
>>>> On Mar 24, 2008, at 10:25 PM, Matthew Knepley wrote:
>>>>> On Mon, Mar 24, 2008 at 10:14 PM, Barry Smith <bsmith at mcs.anl.gov>
>>>>> wrote:
>>>>>>
>>>>>>  Matt,
>>>>>>
>>>>>>   The sed is so trivial it is silly to even think about replacing
>>>>>> it with python!  I did not realize until after reading Lisandro's
>>>>>> email
>>>>>
>>>>> What does that have to do with anything? If its so trivial, then  
>>>>> it
>>>>> won't
>>>>> take any time at all. This is at least the third time I have had  
>>>>> to
>>>>> fool
>>>>> with this sed stuff (I already reported that sed bug two months
>>>>> ago).
>>>>> I do not want to do it again. Is there any justification, except
>>>>> inertia,
>>>>> for keeping that in sed?
>>>>>
>>>>
>>>>   Not having hundreds of dinky little python scripts lying around
>>>> that do the same thing as Unix utilities is a good reason.
>>>>
>>>>  If you write the entire "install:" rule in python that would be
>>>> great,
>>>> then you could start on some of the other rules in conf/rules
>>>> I am only objecting to replacing Unix one-liners with python one
>>>> liners.
>>>
>>> Fine, but you just asked for a lot more Python then 1 line to check
>>> which form of
>>> the -i flag is on the machine.
>>
>>    Yes, but that is the autoconf model! You wanted the autoconf
>> model, not me!
>> You first tried it with autoconf, not possible, so you wrote a better
>> than autoconf
>> in python. I never asked anyone to make a conf system, I was  
>> perfectly
>> happy
>> requiring people to write the correct flags directly into
>> petscconf :-). What bothers
>> me about one-line python scripts to fix Unix weirdness is now you  
>> have
>> two
>> models (some things you fix by running config/configure.py and
>> figuring things
>> out and some things you fix by replacing Unix with python). One thing
>> you
>> should know about me is I HATE HATE HATE HATE using two models for
>> doing something at the
>> same time (this is why I hate Mathematica and PERL, they each support
>> about
>> 20 different programming models that can be used together). So now we
>> have
>> reached the root if the issue; in my mind if you introduce a new  
>> model
>> approach to
>> solving some problem you toss the old, you don't use them both  
>> together!
>
> I am all for consistency. However I have a different interpretation of
> what constitutes
> the model. I thought the model was
>
>  1) Test a set of tools, e.g. compilers, make, ...
>
>  2) Customize the use of each based upon our tests
>
>  3) Use the set of tools required for each build task
>
> I think I am proposing a decision for 3), namely replacing one tool
> with another. We
> already do this, for instance when we link with a linker or a
> compiler. I think we should
> eliminate all uses of sed with python.

   I think that is silly; sed is a perfectly fine tool, like all unix
utilities it just has some whacked behavior, that in this case
can be easily fixed by having a
SED_INPLACE macro.

   Why is SED so special to be replaced by python, why not
cp or all the other things that we have config macros for?



> Notice that this is not wasted
> work, as it will
> survive when eventually everything is replaced by Python.

It is because when the install: rule is replaced by
python it will not be a line by line replacement so your
python sed script will not be needed (it would just make the
python script more cumbersome.)

I think a make rule by rule change to python is a far
better way to go then replacing individual lines in the rules
with python scripts and then later trying to merge those individual
line python scripts together.



    Barry


>
>
>   Matt
>
>>    Barry
>>>
>>>
>>>  Matt
>>>
>>>>   Barry
>>>>
>>>>
>>>>
>>>>
>>>>> Matt
>>>>>
>>>>>> that the sed -i option behaved differently on different systems.
>>>>>>
>>>>>>  Barry
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mar 24, 2008, at 10:07 PM, Matthew Knepley wrote:
>>>>>>> On Mon, Mar 24, 2008 at 9:50 PM, Barry Smith  
>>>>>>> <bsmith at mcs.anl.gov>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Mar 24, 2008, at 10:57 AM, Lisandro Dalcin wrote:
>>>>>>>>> Barry, things are still broken. I think that at some point we
>>>>>>>>> have
>>>>>>>>> to
>>>>>>>>> review the 'install:' target  more carefully.
>>>>>>>>>
>>>>>>>>> First, the 'sed' command i being called in a wrong way.
>>>>>>>>
>>>>>>>> This is not true; the sed is being called correctly. The  
>>>>>>>> problem
>>>>>>>> is that -i
>>>>>>>> is not a standard sed option and different systems gnu and
>>>>>>>> freebsd
>>>>>>>> treat
>>>>>>>> it differently. freebsd requires a space between the -i and the
>>>>>>>> suffix;
>>>>>>>> gnu has no space; gnu also allows the use of -i to indicate no
>>>>>>>> backup
>>>>>>>> while freebsd expects -i ""
>>>>>>>>
>>>>>>>> Your patch works on POS gnu systems, but is broken on far
>>>>>>>> superior
>>>>>>>> Apple MacOS X systems! :-)
>>>>>>>>
>>>>>>>> Matt you need to add a config/configure.py test to detect the
>>>>>>>> type of sed -i it is.
>>>>>>>
>>>>>>> I totally disagree. We should ditch all this crap, and just  
>>>>>>> write
>>>>>>> nice, PORTABLE
>>>>>>> Python code. I will do it. I just need someone to explain what
>>>>>>> this
>>>>>>> sed is doing.
>>>>>>>
>>>>>>> Matt
>>>>>>>
>>>>>>> --
>>>>>>> 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
>