[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: petscvariables: hardwired build dir instead of install dir
On Mar 24, 2008, at 11:26 PM, Matthew Knepley wrote:
On Mon, Mar 24, 2008 at 10:53 PM, Barry Smith <bsmith@xxxxxxxxxxx>
wrote:
On Mar 24, 2008, at 10:42 PM, Matthew Knepley wrote:
On Mon, Mar 24, 2008 at 10:38 PM, Barry Smith <bsmith@xxxxxxxxxxx>
wrote:
On Mar 24, 2008, at 10:25 PM, Matthew Knepley wrote:
On Mon, Mar 24, 2008 at 10:14 PM, Barry Smith <bsmith@xxxxxxxxxxx>
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@xxxxxxxxxxx>
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