On Tue, Oct 6, 2009 at 3:12 AM, Dr. David Kirkby <david.kir...@onetel.net>wrote:
>
> Simon King wrote:
> > Hi!
> >
> > On Oct 6, 9:22 am, Robert Bradshaw <rober...@math.washington.edu>
> > wrote:
> >> Even easier, it seems, would be to to add -m46 (or equivalent) to
> >> CFLAGS directly in sage-env, rather than having the if [ $SAGE64 ...]
> >> test in every spkg-install.
> >
> > This sounds reasonable to me. If I am not mistaken, it has the
> > additional advantage of not breaking anything: Even if an spkg-install
> > adds -m64 to CFLAGS, it would not hurt if sage-env would put "-m64" in
> > CFLAGS, or would it be a problem for a compiler to get "-m64" twice in
> > one line?
> >
> > Simon
>
> I'm not so sure this is a good idea.
>
> Certainly adding -m64 twice is not an issue. There are several bits in
> Sage which do that. Neither the Sun or GNU compilers moan about that - I
> can't speak for other compilers.
>
> An issue would arise however if someone wants to append the option
> -foobar to CFLAGS, since it is needed for a particular package. So they
> put in spkg-install:
>
>
> CFLAGS="$CFLAGS -foobar"
> export CFLAGS
>
> Now every package built after that one would have CFLAGS as
>
> -m64 -foobar
>
> whether or not it wants the -foobar, since it has been exported.
>
Then:
">> Is there not a way to invoke a bash script in such a way that it
>> can't change the invoking environment?
>I do not know of one. Perhaps there is."
Heh. Not only is it possible, we *already* do invoke our scripts in such a
way.
Putting the above in an spkg-install would *only* impact installation of
that one package and nothing else. This is because the Sage script
"local/bin/sage-spkg" runs the spkg-install using the following line:
time ./spkg-install
Thus the environment of spkg-install for one package has absolutely no
impact at all on the environment of the next package. If sage-spkg had run
spkg-install differently (e.g., "source spkg-install") then the environment
would indeed be corrupted.
In case you aren't convinced, here's proof. Notice that CFLAGS doesn't
"infect" the environment that the script "c" below sees:
----------------------------------------
flat:x wstein$ more a
export CFLAGS=""
./b
./c
flat:x wstein$ more b
export CFLAGS="foo"
echo $CFLAGS
flat:x wstein$ more c
echo $CFLAGS
flat:x wstein$ ./a
foo
flat:x wstein$
----------------------------------------
Also, the suggestion(s) to put the -m64 stuff in sage-env make a huge amount
of sense to me. The more that is factored out and less redundant in the
spkg's the better. In fact, that's a good general principle in coding.
This code below *should* have been in sage-env, not every single
spkg-install. If that had been the case, I doubt you would be so annoyed by
it, since you could trivially just delete the Darwin part:
if [ `uname` = "Darwin" -a $SAGE64="yes"]
CFLAGS="$FLAGS -m64"
CXXFLAGS="$CXXFLAGS -m64"
fi
> Hence it's probably safer to have each spkg-install start with
>
> CFLAGS=$SAGE64_CFLAG
>
> and add others as needed.
>
This violates the "factor it out" rule. In fact I am *highly* suspicious of
any sentence of the form "have each spkg-install ...". If there is anything
that somebody wants to put in every spkg-install, then it should be factored
out. The one exception to this is the very good idea to add:
if [ "$SAGE_LOCAL" = "" ]; then
echo "SAGE_LOCAL undefined ... exiting";
echo "Maybe run 'sage -sh'?"
exit 1
fi
to the top of spkg-install's. Since there is no way to factor that out,
since the whole point of it is to check that the code is being run in the
right scope.
>
> This would not be an issue if someone write
>
> ./configure CFLAGS="$CFLAGS -foobar"
>
> as the environment variable CFLAGS would not be corrupted. But I think
> in some cases it may be necessary to export CFLAGS, in which case
> relying on anything being there might be unwise.
>
> Dave
>
>
>
>
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
