Re: [sage-devel] Re: Is 'flex' needed to build Sage?
> > Apart from moving to the latest upstream I think the singular spkg > > is due for a spring clean. It build an enormous amount of targets > > in a way that looks like a very careful choreography and apart > > from libsingular and the singular binary there is no indication > > sage uses any of the other stuff built. > > It does take a long time to build compared to most other packages, which > is probably due to the fact the package is large and so has a lot of > source code. Well I am trying that now. Running the test against a lighter version of singular without what looks like extra baggage. It will have some impact on the build time but probably not as much as you would like. On my computer: before: merge time: 22 minutes and 36 seconds. after : merge time: 18 minutes and 52 seconds. Francois -- 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
[sage-devel] Re: Is 'flex' needed to build Sage?
On 7 Jun., 02:02, William Stein wrote:
> On Sun, Jun 6, 2010 at 4:35 PM, leif wrote:
> > I thought in this thread we were only talking about its build system,
> > not the source code or Singular's quality in general.
>
> > I cannot resist to give some excerpts from just src/Singular/
> > Makefile.in:
>
> > ##
> > ## various programs
> > ##
> > @SET_MAKE@
> > CC = @CC@
> > LD = @LD@
> > CXX = @CXX@
> > LEX = sh flexer.sh
>
> > PERL = @PERL@
> > BISON = bison
> > INSTALL = @INSTALL@
> > INSTALL_PROGRAM = @INSTALL_PROGRAM@
> > INSTALL_DATA = @INSTALL_DATA@
> > MKINSTALLDIRS = ./mkinstalldirs
> > LN_S = @LN_S@
>
> > ...
>
> > SOURCES=${CSOURCES} ${CXXSOURCES} \
> > grammar.y scanner.l libparse.l \
> > utils.cc utils.h \
> > tesths.cc mpsr_Tok.cc claptmpl.cc
>
> > ...
>
> > ##
> > ## Build Targets
> > ##
> > .l.cc:
> > �...@if test -r scanner.cc; then \
> > touch scanner.cc ;\
> > elif test "x${LEX}" = x; then \
> > echo Error: no lex given, could not rebuilt scanner.cc;\
> > exit 1; \
> > fi
> > ${LEX} -s -I -t $< > scanner.cc.lmp
> > cp scanner.cc.lmp scanner.cc
>
> > .y.cc:
> > �...@if test -r grammar.cc; then \
> > touch grammar.cc ;\
> > else \
> > if test "x${BISON}" = x; then \
> > echo Error: no bison given, could not rebuilt grammar.cc;\
> > exit 1; \
> > fi;\
> > ${BISON} -d -t -o grammar.cc $<;\
> > chmod +x testgh;\
> > ./testgh;\
> > fi
>
> > Note that these are all from the same file. You could also take a look
> > at flexer.sh...
>
> > -Leif
>
> To make your complaints clearer and more *constructive*, I wonder if
> you could explain roughly how you would rewrite the above code?
We agreed that we will only do the simple workaround at #9160 s.t. it
builds on Solaris (too) at the moment.
(By the way, I did not complain.)
There's of course room for another ticket.
What's wrong with the above snippets should be clear to everyone
interested... ;-)
First of all, if you use configure/autotools, don't hardcode lex and
yacc (in this case, actually bison and a shell script that just deals
with different versions of flex, and does not even test if or where
flex is present).
Less of a problem if up-to-date versions of the generated files are
shipped to "end users" (with correct m-times; as said before, in
general ordinary users shouldn't need "developer tools" like lex&yacc
or autotools).
The assumption that there is only one source file matching the .l.cc
rule is false.
That rule has a "misplaced" if-elif-fi.
Both rules assume that any present generated file is always up-to-
date.
-Leif
--
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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On Sun, Jun 6, 2010 at 5:06 PM, François Bissey wrote: >> I'm sure Singular has a process to fix the problems you mention. >> All you have to do is send a 'diff -Naur' patch that improves the build. >> >> You got hundreds of megabytes of code for free and you're complaining >> because the install script isn't written the way you advocate? >> >> Advocacy is volunteering. >> >> Send them a thank-you note for all the free code and include a patch file. >> >> Tim >> >> "Open source... now it's YOUR problem to solve" -- daly > OK I sympathise, that's in the same line as > "there are two groups of people: those who can and those who complain" > I volunteer and try to do stuff but while I can see some problems I am not > necessarily competent to do something about it. > Actually in the case of singular I may end up making it worse. +1 I would like to very strongly encourage people to complain about anything they find very frustrating in Sage, since it is difficult to know what to fix without these complaints. This sort of user feedback is extremely valuable, especially from users who aren't capable of contributing back. You can use this link to complain anonymously: http://spreadsheets.google.com/viewform?key=pCwvGVwSMxTzT6E2xNdo5fA I'll try to be as constructive as possible with my complaints about upstream components though. In the past, I've sometimes not done so, and always regretted it. > But I think the singular spkg can be improved and that I think I can do. > I will certainly have a shoot, once I have marked the 200 copies that are > coming my way in the next week. Cool, thanks! And if nothing else you can post some of your findings to http://wiki.sagemath.org/days23.5 so somebody like me can think about this at the Sage/Singular sage days. William > > Francois > > -- > 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 > -- William Stein 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
> I'm sure Singular has a process to fix the problems you mention. > All you have to do is send a 'diff -Naur' patch that improves the build. > > You got hundreds of megabytes of code for free and you're complaining > because the install script isn't written the way you advocate? > > Advocacy is volunteering. > > Send them a thank-you note for all the free code and include a patch file. > > Tim > > "Open source... now it's YOUR problem to solve" -- daly OK I sympathise, that's in the same line as "there are two groups of people: those who can and those who complain" I volunteer and try to do stuff but while I can see some problems I am not necessarily competent to do something about it. Actually in the case of singular I may end up making it worse. But I think the singular spkg can be improved and that I think I can do. I will certainly have a shoot, once I have marked the 200 copies that are coming my way in the next week. Francois -- 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On Sun, Jun 6, 2010 at 4:35 PM, leif wrote:
> On 7 Jun., 01:19, William Stein wrote:
>> On Sun, Jun 6, 2010 at 4:10 PM, Dr. David Kirkby
>>
>> wrote:
>> > On 06/ 6/10 11:48 PM, François Bissey wrote:
>>
>> >> yes singular is a downright mess, upstream and in sage.
>>
>> > I'm glad I'm not alone in my view.
>>
>> I just want to clarify something again (which David already
>> clarified): you guys are both talking about the build system, and I'm
>> talking only about the C++ source code. So we aren't disagreeing.
>
> I thought in this thread we were only talking about its build system,
> not the source code or Singular's quality in general.
>
> I cannot resist to give some excerpts from just src/Singular/
> Makefile.in:
>
> ##
> ## various programs
> ##
> @SET_MAKE@
> CC = @CC@
> LD = @LD@
> CXX = @CXX@
> LEX = sh flexer.sh
>
> PERL = @PERL@
> BISON = bison
> INSTALL = @INSTALL@
> INSTALL_PROGRAM = @INSTALL_PROGRAM@
> INSTALL_DATA = @INSTALL_DATA@
> MKINSTALLDIRS = ./mkinstalldirs
> LN_S = @LN_S@
>
> ...
>
> SOURCES=${CSOURCES} ${CXXSOURCES} \
> grammar.y scanner.l libparse.l \
> utils.cc utils.h \
> tesths.cc mpsr_Tok.cc claptmpl.cc
>
> ...
>
> ##
> ## Build Targets
> ##
> .l.cc:
> �...@if test -r scanner.cc; then \
> touch scanner.cc ;\
> elif test "x${LEX}" = x; then \
> echo Error: no lex given, could not rebuilt scanner.cc;\
> exit 1; \
> fi
> ${LEX} -s -I -t $< > scanner.cc.lmp
> cp scanner.cc.lmp scanner.cc
>
> .y.cc:
> �...@if test -r grammar.cc; then \
> touch grammar.cc ;\
> else \
> if test "x${BISON}" = x; then \
> echo Error: no bison given, could not rebuilt grammar.cc;\
> exit 1; \
> fi;\
> ${BISON} -d -t -o grammar.cc $<;\
> chmod +x testgh;\
> ./testgh;\
> fi
>
> Note that these are all from the same file. You could also take a look
> at flexer.sh...
>
> -Leif
To make your complaints clearer and more *constructive*, I wonder if
you could explain roughly how you would rewrite the above code?
-- William
--
William Stein
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
[sage-devel] Re: Is 'flex' needed to build Sage?
On 7 Jun., 01:29, Tim Daly wrote: > I'm sure Singular has a process to fix the problems you mention. > All you have to do is send a 'diff -Naur' patch that improves the build. Of course. But the current workaround just happens in spkg-install. > You got hundreds of megabytes of code for free and you're complaining > because the install script isn't written the way you advocate? Tell this some Sage users if they complain... ;-) (Especially in the context of MS Windows/Cygwin.) > "Open source... now it's YOUR problem to solve" -- daly There are commercial products you're more left alone with (or pay much for support hotlines). -Leif -- 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
[sage-devel] Re: Is 'flex' needed to build Sage?
On 7 Jun., 01:19, William Stein wrote:
> On Sun, Jun 6, 2010 at 4:10 PM, Dr. David Kirkby
>
> wrote:
> > On 06/ 6/10 11:48 PM, François Bissey wrote:
>
> >> yes singular is a downright mess, upstream and in sage.
>
> > I'm glad I'm not alone in my view.
>
> I just want to clarify something again (which David already
> clarified): you guys are both talking about the build system, and I'm
> talking only about the C++ source code. So we aren't disagreeing.
I thought in this thread we were only talking about its build system,
not the source code or Singular's quality in general.
I cannot resist to give some excerpts from just src/Singular/
Makefile.in:
##
## various programs
##
@SET_MAKE@
CC = @CC@
LD = @LD@
CXX = @CXX@
LEX = sh flexer.sh
PERL= @PERL@
BISON = bison
INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA= @INSTALL_DATA@
MKINSTALLDIRS = ./mkinstalldirs
LN_S= @LN_S@
...
SOURCES=${CSOURCES} ${CXXSOURCES} \
grammar.y scanner.l libparse.l \
utils.cc utils.h \
tesths.cc mpsr_Tok.cc claptmpl.cc
...
##
## Build Targets
##
.l.cc:
@if test -r scanner.cc; then \
touch scanner.cc ;\
elif test "x${LEX}" = x; then \
echo Error: no lex given, could not rebuilt scanner.cc;\
exit 1; \
fi
${LEX} -s -I -t $< > scanner.cc.lmp
cp scanner.cc.lmp scanner.cc
.y.cc:
@if test -r grammar.cc; then \
touch grammar.cc ;\
else \
if test "x${BISON}" = x; then \
echo Error: no bison given, could not rebuilt grammar.cc;\
exit 1; \
fi;\
${BISON} -d -t -o grammar.cc $<;\
chmod +x testgh;\
./testgh;\
fi
Note that these are all from the same file. You could also take a look
at flexer.sh...
-Leif
--
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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
I'm sure Singular has a process to fix the problems you mention. All you have to do is send a 'diff -Naur' patch that improves the build. You got hundreds of megabytes of code for free and you're complaining because the install script isn't written the way you advocate? Advocacy is volunteering. Send them a thank-you note for all the free code and include a patch file. Tim "Open source... now it's YOUR problem to solve" -- daly Dr. David Kirkby wrote: On 06/ 6/10 11:48 PM, François Bissey wrote: yes singular is a downright mess, upstream and in sage. I'm glad I'm not alone in my view. Apart from moving to the latest upstream I think the singular spkg is due for a spring clean. It build an enormous amount of targets in a way that looks like a very careful choreography and apart from libsingular and the singular binary there is no indication sage uses any of the other stuff built. It does take a long time to build compared to most other packages, which is probably due to the fact the package is large and so has a lot of source code. If a lot of the targets are unnecessary, then I suspect the build time could be reduced. It took 40 minutes on my old 900 MHz SPARC, though I could probably reduce that if targets can be built in parallel. But even then, it is still going to be quite lengthy. I have just read William's opinion and it may be true that is generally easy to build. But reproducing the set up used in the sage spkg from a packaging point of view is quite difficult. Francois Dave -- 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On Sun, Jun 6, 2010 at 4:10 PM, Dr. David Kirkby wrote: > On 06/ 6/10 11:48 PM, François Bissey wrote: > >> yes singular is a downright mess, upstream and in sage. > > I'm glad I'm not alone in my view. I just want to clarify something again (which David already clarified): you guys are both talking about the build system, and I'm talking only about the C++ source code. So we aren't disagreeing. -- William Stein 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On 06/ 6/10 11:48 PM, François Bissey wrote: yes singular is a downright mess, upstream and in sage. I'm glad I'm not alone in my view. Apart from moving to the latest upstream I think the singular spkg is due for a spring clean. It build an enormous amount of targets in a way that looks like a very careful choreography and apart from libsingular and the singular binary there is no indication sage uses any of the other stuff built. It does take a long time to build compared to most other packages, which is probably due to the fact the package is large and so has a lot of source code. If a lot of the targets are unnecessary, then I suspect the build time could be reduced. It took 40 minutes on my old 900 MHz SPARC, though I could probably reduce that if targets can be built in parallel. But even then, it is still going to be quite lengthy. I have just read William's opinion and it may be true that is generally easy to build. But reproducing the set up used in the sage spkg from a packaging point of view is quite difficult. Francois Dave -- 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On 06/ 6/10 11:39 PM, William Stein wrote: In case anybody from Singular is reading this -- the above is the opinion of David and not the Sage project as a whole. I'll add that, in my experience, Singular is fairly easy to build and portable, more so than many other programs. When I've personally poked around in the Singular source code and actually tried to understand the code, it's been surprisingly easy to understand, compared to many other sophisticated C++ programs. That may be true, but the build process is far from clean. Type $ configure $ make $ make distclean and it appears to delete a load of files. Then type: $ configure $ make and it reports: make: `/tmp/Singular-3-1-1/ix86-SunOS/Singular-3-1-1' is up to date. in other words, the 'make distclean' is not cleaning things properly. There is no 'make check' or 'make test'. The configure script silently ignores what appear to be unsupported options like '--without-bison' I've not looked at the C/C++ source code, but accept it might be quite clear. The build process is far from clean. The spkg-install in Sage is also rather messy, with tons of options that are not listed by the configure script as being valid options. Regarding multiple copies of install-sh, please note that like Sage, Singular is built up from other libraries and components. One could criticize Sage on the same grounds for including multiple copies of various autoconf scripts in the various src/ subdirectories of spkg's. As such, I think this hack is the best we can do. It at least allows Sage to build when flex is not installed. I think using touch is reasonable given the circumstances. Me too. Dave -- 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On Sun, Jun 6, 2010 at 3:48 PM, François Bissey wrote: >> I've tested on multiple Solaris systems, both with and without 'flex' in >> the path - see trac ticket for further details. >> >> The more I look at the Singular package in Sage, the more I realise it is >> a complete mess. There are 5 copies of install-sh for example. Sage's >> spkg-install has options that are not listed as options to the Singular >> 'configure' script, and don't do what their names imply (i.e. >> --without-bison and --without-lex). >> >> I've just downloaded the latest Singular source, and that is no less of a >> mess. So both Sage's spkg-install and the current Singular source code >> are a bit poor in my honest opinion. >> >> As such, I think this hack is the best we can do. >> >> It at least allows Sage to build when flex is not installed. > yes singular is a downright mess, upstream and in sage. > Apart from moving to the latest upstream I think the singular spkg > is due for a spring clean. It build an enormous amount of targets > in a way that looks like a very careful choreography and apart > from libsingular and the singular binary there is no indication > sage uses any of the other stuff built. > > I have just read William's opinion and it may be true that is generally easy > to build. But reproducing the set up used in the sage spkg from a packaging > point of view is quite difficult. My main point is that it can be unduly offensive to criticize software quality based purely on looking for a few minutes and deciding it looks complicated or ugly. I think one has to take a broader view and consider how the software works in practice, how easy it is to understand when you're seriously interesting in hacking on the code, etc. A huge amount of effort has gone into Singular, and I greatly appreciate that it is open source. I think the Sage project has a very good relationship with the Singular project, and I hope criticism of the quality of their work will be constructive and not offensive. That's all. It would be cool if some the ideas you guys have could be added to http://wiki.sagemath.org/days23.5 which is the joint Sage/Singular meeting this summer. -- William -- William Stein 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
> I've tested on multiple Solaris systems, both with and without 'flex' in > the path - see trac ticket for further details. > > The more I look at the Singular package in Sage, the more I realise it is > a complete mess. There are 5 copies of install-sh for example. Sage's > spkg-install has options that are not listed as options to the Singular > 'configure' script, and don't do what their names imply (i.e. > --without-bison and --without-lex). > > I've just downloaded the latest Singular source, and that is no less of a > mess. So both Sage's spkg-install and the current Singular source code > are a bit poor in my honest opinion. > > As such, I think this hack is the best we can do. > > It at least allows Sage to build when flex is not installed. yes singular is a downright mess, upstream and in sage. Apart from moving to the latest upstream I think the singular spkg is due for a spring clean. It build an enormous amount of targets in a way that looks like a very careful choreography and apart from libsingular and the singular binary there is no indication sage uses any of the other stuff built. I have just read William's opinion and it may be true that is generally easy to build. But reproducing the set up used in the sage spkg from a packaging point of view is quite difficult. Francois -- 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On Sun, Jun 6, 2010 at 3:27 PM, Dr. David Kirkby wrote: > On 06/ 6/10 07:29 PM, leif wrote: >> >> On 6 Jun., 19:02, "Dr. David Kirkby" wrote: > >>> Could I twist your arm to review the changes? >> >> Be a little patient, awaiting 4.4.4.alpha0... >> (And in principle the patch should be tested on other Solaris systems, >> too... I currently can only give it a "Linux-ok" - as soon as the >> sysloads drop reasonably...) >> >> >> -Leif >> > > I've tested on multiple Solaris systems, both with and without 'flex' in the > path - see trac ticket for further details. > > The more I look at the Singular package in Sage, the more I realise it is a > complete mess. There are 5 copies of install-sh for example. Sage's > spkg-install has options that are not listed as options to the Singular > 'configure' script, and don't do what their names imply (i.e. > --without-bison and --without-lex). > > I've just downloaded the latest Singular source, and that is no less of a > mess. So both Sage's spkg-install and the current Singular source code are a > bit poor in my honest opinion. ^^ In case anybody from Singular is reading this -- the above is the opinion of David and not the Sage project as a whole. I'll add that, in my experience, Singular is fairly easy to build and portable, more so than many other programs. When I've personally poked around in the Singular source code and actually tried to understand the code, it's been surprisingly easy to understand, compared to many other sophisticated C++ programs. Regarding multiple copies of install-sh, please note that like Sage, Singular is built up from other libraries and components. One could criticize Sage on the same grounds for including multiple copies of various autoconf scripts in the various src/ subdirectories of spkg's. > As such, I think this hack is the best we can do. > > It at least allows Sage to build when flex is not installed. I think using touch is reasonable given the circumstances. -- William -- William Stein 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On 06/ 6/10 07:29 PM, leif wrote: On 6 Jun., 19:02, "Dr. David Kirkby" wrote: Could I twist your arm to review the changes? Be a little patient, awaiting 4.4.4.alpha0... (And in principle the patch should be tested on other Solaris systems, too... I currently can only give it a "Linux-ok" - as soon as the sysloads drop reasonably...) -Leif I've tested on multiple Solaris systems, both with and without 'flex' in the path - see trac ticket for further details. The more I look at the Singular package in Sage, the more I realise it is a complete mess. There are 5 copies of install-sh for example. Sage's spkg-install has options that are not listed as options to the Singular 'configure' script, and don't do what their names imply (i.e. --without-bison and --without-lex). I've just downloaded the latest Singular source, and that is no less of a mess. So both Sage's spkg-install and the current Singular source code are a bit poor in my honest opinion. As such, I think this hack is the best we can do. It at least allows Sage to build when flex is not installed. Dave -- 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
[sage-devel] Re: Is 'flex' needed to build Sage?
On 6 Jun., 19:02, "Dr. David Kirkby" wrote: > On 06/ 6/10 04:43 PM, leif wrote: > > [1]http://www.sagemath.org/doc/developer/disseminating_code.html#dissemi... > > [2]http://www.sagemath.org/doc/developer/producing_spkgs.html#producing-... > > [3]http://www.sagemath.org/doc/developer/patching_spkgs.html#patching-a-... > > The section "Disseminating Code for Sage" does seem rather mis-placed to me, > though I can't think of how I would improve it. Most probably Minh will have some good ideas.. :) > Things like creating .spkg's should arguably not be subsections of > "Disseminating Code for Sage" > > The section about .spkg's called "Avoiding trouble" could certainly do with > expansion on these issues. Thought of that, too, but it should be in both subsections :-/ > http://www.sagemath.org/doc/developer/producing_spkgs.html#avoiding-t... > > It's only seven sentences long. It should certainly state that programs used > by > developers (yacc, lex, bison, flex, autoconf, automake should not be assumed > to > be available). However, from discussions on sage-support, the optional package > Lie needs bison. Perhaps the bison output for that could be added into the > package, so one does not need bison. I don't know how practical that would be, > and given it is an optional package and has a more fundamental flaw, I can't > be > bothered to try to do anything about that - installing bison would be easiest. Just for the record, some packages (I don't think in Sage) require skeleton files or even libraries, too (i.e. providing the pregenerated files does not always suffice). > I doubt however there is much a Sage developer could have done to notice the > problem with Singular. make -n ? ;-) (aka --dry-run) (Obviously this depends on the system as well; usually one had to run ./configure before...) perhaps grep in (test) install.log (testing on mostly vanilla "user" installations is another option) > In general, they are not going to look into the source > code of the individual packages, and compare time stamps on files. Even if > they > do, with 'ls -l' they are not going to see that a file is one second older > than > another, as the dates are back in 2008 and this information is not shown in > the > normal output of 'ls'. How many of them will know what 'yacc' and 'lex' do > anyway? (Or their GNU clones 'bison' and 'flex'). > > Some things I look at in Sage and wonder how anyone could be so stupid to > miss. > In this case, I don't think any Sage developer can be blamed. I suspect they > have untarred the Singular source code, so the dates have remained what they > originally were. > > Anyway, it is good that it is found. Yes, but "touch" in spkg-install is an ugly workaround (to be removed in the long run), not a bugfix. ;-) > Could I twist your arm to review the changes? Be a little patient, awaiting 4.4.4.alpha0... (And in principle the patch should be tested on other Solaris systems, too... I currently can only give it a "Linux-ok" - as soon as the sysloads drop reasonably...) -Leif -- 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
Re: [sage-devel] Re: Is 'flex' needed to build Sage?
On 06/ 6/10 04:43 PM, leif wrote:
On 6 Jun., 12:27, Willem Jan Palenstijn wrote:
The way this usually works is that packages are shipped with the output of
flex, so that flex doesn't have to be run again if the user doesn't have it.
This is a more general problem ([f]lex and yacc/bison are just
examples; the auto-tools are another one).
Anyone who includes/updates an spkg should make sure that no
"developer tools" are required to perform a conventional "user" build/
install, i.e.:
- the pregenerated files are included in the source tarball,
- file modification times do not cause unintended dependencies/
rebuild of provided files.
Unfortunately the sections on spkgs in the Developer's Guide have been
split into creation of new and update/patching of existing spkgs
("Producing New Sage Packages" [2], "Patching a Sage Package" [3]);
I'm not sure if everybody will read the introductory "Disseminating
Code for Sage" [1]. Perhaps a hint in potentially affected spkgs'
SPKG.txt wouldn't be bad, too.
(The file permissions/ownership issue could also be mentioned in these
sections.)
-Leif
[1]
http://www.sagemath.org/doc/developer/disseminating_code.html#disseminating-code-for-sage
[2]
http://www.sagemath.org/doc/developer/producing_spkgs.html#producing-new-sage-packages
[3]
http://www.sagemath.org/doc/developer/patching_spkgs.html#patching-a-sage-package
The section "Disseminating Code for Sage" does seem rather mis-placed to me,
though I can't think of how I would improve it.
Things like creating .spkg's should arguably not be subsections of
"Disseminating Code for Sage"
The section about .spkg's called "Avoiding trouble" could certainly do with
expansion on these issues.
http://www.sagemath.org/doc/developer/producing_spkgs.html#avoiding-troubles
It's only seven sentences long. It should certainly state that programs used by
developers (yacc, lex, bison, flex, autoconf, automake should not be assumed to
be available). However, from discussions on sage-support, the optional package
Lie needs bison. Perhaps the bison output for that could be added into the
package, so one does not need bison. I don't know how practical that would be,
and given it is an optional package and has a more fundamental flaw, I can't be
bothered to try to do anything about that - installing bison would be easiest.
I doubt however there is much a Sage developer could have done to notice the
problem with Singular. In general, they are not going to look into the source
code of the individual packages, and compare time stamps on files. Even if they
do, with 'ls -l' they are not going to see that a file is one second older than
another, as the dates are back in 2008 and this information is not shown in the
normal output of 'ls'. How many of them will know what 'yacc' and 'lex' do
anyway? (Or their GNU clones 'bison' and 'flex').
Some things I look at in Sage and wonder how anyone could be so stupid to miss.
In this case, I don't think any Sage developer can be blamed. I suspect they
have untarred the Singular source code, so the dates have remained what they
originally were.
Anyway, it is good that it is found.
Could I twist your arm to review the changes?
Dave
--
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
[sage-devel] Re: Is 'flex' needed to build Sage?
On 6 Jun., 12:27, Willem Jan Palenstijn wrote:
> On Sun, Jun 06, 2010 at 09:14:09AM +0100, Dr. David Kirkby wrote:
> > I've tried twice to build Sage on a machine in which 'flex' was not in
> > the path. It has both times failed with:
>
> > make install in Singular
> > make[4]: Entering directory
> > `/export/home/drkirkby/32/sage-4.4.3/spkg/build/singular-3-1-0-4-20100214/src/Singular'
> > sh flexer.sh -I -Pyylp -t libparse.l >libparse.cc.lmp
> > flexer.sh: flex: not found
> > flexer.sh: test: argument expected
> > make[4]: *** [libparse.cc] Error 1
>
> > So is flex a requirement to build Sage? If it is, then I'll add to the
> > 'prereq' script a test for flex. If, which I doubt, it is only needed on
> > Solaris, then I'll make the test specific to Solaris.
>
> The way this usually works is that packages are shipped with the output of
> flex, so that flex doesn't have to be run again if the user doesn't have it.
This is a more general problem ([f]lex and yacc/bison are just
examples; the auto-tools are another one).
Anyone who includes/updates an spkg should make sure that no
"developer tools" are required to perform a conventional "user" build/
install, i.e.:
- the pregenerated files are included in the source tarball,
- file modification times do not cause unintended dependencies/
rebuild of provided files.
Unfortunately the sections on spkgs in the Developer's Guide have been
split into creation of new and update/patching of existing spkgs
("Producing New Sage Packages" [2], "Patching a Sage Package" [3]);
I'm not sure if everybody will read the introductory "Disseminating
Code for Sage" [1]. Perhaps a hint in potentially affected spkgs'
SPKG.txt wouldn't be bad, too.
(The file permissions/ownership issue could also be mentioned in these
sections.)
-Leif
[1]
http://www.sagemath.org/doc/developer/disseminating_code.html#disseminating-code-for-sage
[2]
http://www.sagemath.org/doc/developer/producing_spkgs.html#producing-new-sage-packages
[3]
http://www.sagemath.org/doc/developer/patching_spkgs.html#patching-a-sage-package
--
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
