Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#14406 closed enhancement (fixed)

Various prereq fixes

Reported by: jdemeyer Owned by: drkirkby
Priority: major Milestone: sage-5.9
Component: porting Keywords:
Cc: jdemeyer, leif, jpflori Merged in: sage-5.9.beta4
Authors: Jeroen Demeyer, Jean-Pierre Flori Reviewers: Jean-Pierre Flori, Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by jpflori)

  • Allow Sage to build on Cygwin without setting SAGE_PORT.
  • Don't check for sqrtl() which is apparently not needed (Cygwin doesn't have it, yet Sage builds).
  • Remove all checks for the deprecated variable SAGE_FORTRAN_LIB.
  • Remove AC_ARG_VAR(SAGE_FORTRAN) which is a deprecated variable.
  • Check for tar before actually untarring the prereq tarball (originally #14407), only do these checks if SAGE_PORT is unset.

Copy http://boxen.math.washington.edu/home/jdemeyer/spkg/prereq-1.2.tar.gz to spkg/base (diff)

Apply trac_14406+reviewer-v3.patch

Attachments (3)

prereq-1.2.diff (3.9 KB) - added by jdemeyer 7 years ago.
14406_cygwin_prereq.patch (14.9 KB) - added by jdemeyer 7 years ago.
trac_14406+reviewer-v3.patch (15.7 KB) - added by jpflori 7 years ago.

Download all attachments as: .zip

Change History (62)

comment:1 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:2 Changed 7 years ago by jdemeyer

  • Authors set to Jeroen Demeyer
  • Cc jdemeyer leif jpflori added
  • Component changed from porting: Cygwin to porting
  • Description modified (diff)
  • Owner changed from tbd to drkirkby
  • Summary changed from Update prereq for Cygwin to Various prereq fixes

comment:3 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:4 Changed 7 years ago by jdemeyer

  • Description modified (diff)

Changed 7 years ago by jdemeyer

comment:5 Changed 7 years ago by jdemeyer

  • Status changed from new to needs_review

comment:6 Changed 7 years ago by jpflori

In the prereq install script, the Solaris part could be a little bit polished. The first sentence includes a disturbing also:

You MUST also use the GNU version of tar...

whereas nothing precedes it.

I don't really like the fact that both tar and make are tested together in the constructions

if [ -f "/usr/sfw/bin/gtar" ]  && [ -f "/usr/sfw/bin/gmake" ] ; then

The only advantage of doing this is to easily suggest to do

   echo "$ mkdir \$HOME/bins-for-sage" 
   echo "$ cp /usr/sfw/bin/gmake \$HOME/bins-for-sage/make" 
   echo "$ cp /usr/sfw/bin/gtar \$HOME/bins-for-sage/tar" 
   echo "$ export PATH=\$HOME/bins-for-sage:\$PATH" 

I think we'd better split the two tests, i.e. only check for tar in the tar part and for make in the make part. At worst, a naive user will have to run make twice before it passes the prereq checks and will have twice $HAME\bins-for-sage in its PATH.

There are also ugly double spaces before "&&" on the (new) lines 132 and 165 :)

comment:7 Changed 7 years ago by jpflori

We could also include the Solaris parts together with the HP-UX and other strange Unix oses as elif clauses a little down below.

That may look nicer and prevent running "tar --version" twice.

If so, the commented out comments will need just a little rewriting and relocation.

comment:8 Changed 7 years ago by jdemeyer

OK, making changes...

comment:9 follow-ups: Changed 7 years ago by leif

Didn't we want to replace the check for sqrtl() by a check for ?gammal()? (OTOH I don't recall why exactly... ;-) )

Actually, we need both sqrtl() and [lt]gammal() unless we build Cephes, i.e., unless we're on Cygwin(?) or on FreeBSD, or skip the test because SAGE_PORT is set.

comment:10 Changed 7 years ago by kcrisman

Also recall we still don't have logl (#14078) and so things are still weird, though we worked around it there. But I don't have a problem with the Cygwin stuff here; Sage builds as is on Cygwin. I think David originally added that check just to make sure one didn't need stuff like Cephes, but apparently we don't actually use sqrtl() and friends.

comment:11 in reply to: ↑ 9 Changed 7 years ago by jpflori

Replying to leif:

Didn't we want to replace the check for sqrtl() by a check for ?gammal()? (OTOH I don't recall why exactly... ;-) )

Actually, we need both sqrtl() and [lt]gammal() unless we build Cephes, i.e., unless we're on Cygwin(?) or on FreeBSD, or skip the test because SAGE_PORT is set.

We don't build Cephes on Cygwin. On Cygwin, the only *l functions actually needed anywhere in Sage and which caused troubles (and that Cygwin libm does not provide, not sure what it actually provides, but I seem to remember it provides no "long double" functions at all) was "logl" because of R, but we patched R so that its not needed anymore, and the next R upstream version provides a configure option to disable the use of "long double" functions anyway.

comment:12 Changed 7 years ago by jpflori

Here is what was recently included in Cygwin:

Support for the C99 complex functions, except for the "long double" implementations. New APIs: cacos, cacosf, cacosh, cacoshf, carg, cargf, casin, casinf, casinh, casinhf, catan, catanf, catanh, catanhf, ccos, ccosf, ccosh, ccoshf, cexp, cexpf, cimag, cimagf, clog, clogf, conj, conjf, cpow, cpowf, cproj, cprojf, creal, crealf, csin, csinf, csinh, csinhf, csqrt, csqrtf, ctan, ctanf, ctanh, ctanhf. 

See http://cygwin.com/cygwin-ug-net/ov-new1.7.html.

comment:13 Changed 7 years ago by jpflori

And I don't know what the FreeBSD libm lacks that make Sage's compilation fail (except for the logl function for R of course).

comment:14 Changed 7 years ago by jpflori

And of course we could revert the patch for R from #14078 and let Cephes install again on Cygwin. It is just that at the time we were working on #14078, patching R, which is about to get the "without long double" support in a future release seemed easier. I cannot not promise that installing Cephes and then trying to install R without the patch will just work out of the box.

Changed 7 years ago by jdemeyer

comment:15 in reply to: ↑ 9 Changed 7 years ago by jdemeyer

Replying to leif:

Actually, we need both sqrtl() and [lt]gammal() unless we build Cephes

It seems not, Cygwin doesn't have sqrtl(), nor does it build Cephes. Despite this, Sage builds.

comment:16 Changed 7 years ago by jdemeyer

OK, simplified the tar/make checks.

comment:17 Changed 7 years ago by jpflori

Ok, I've slightly recomplexified it :)

comment:18 Changed 7 years ago by jpflori

Oops, something is wrong, coming back with a proper patch.

comment:19 follow-up: Changed 7 years ago by leif

Replying to jdemeyer:

Replying to leif:

Actually, we need both sqrtl() and [lt]gammal() unless we build Cephes

It seems not, Cygwin doesn't have sqrtl(), nor does it build Cephes. Despite this, Sage builds.

IIRC, because we (still) have some special-casing on Cygwin w.r.t. at least (just?) the (long double) gamma functions.


To repeat Karl-Dieter's question: What is Cephes then needed for at all [on e.g. FreeBSD]?

I.e., we should probably check for those functions Cephes provides (and Sage needs) [unless we're on FreeBSD where Cephes gets built anyway, or SAGE_PORT is set].

comment:20 in reply to: ↑ 19 ; follow-up: Changed 7 years ago by jpflori

Replying to leif:

Replying to jdemeyer:

Replying to leif:

Actually, we need both sqrtl() and [lt]gammal() unless we build Cephes

It seems not, Cygwin doesn't have sqrtl(), nor does it build Cephes. Despite this, Sage builds.

IIRC, because we (still) have some special-casing on Cygwin w.r.t. at least (just?) the (long double) gamma functions.

I'll have a look.


To repeat Karl-Dieter's question: What is Cephes then needed for at all [on e.g. FreeBSD]?

Maybe for complex functions "c*" (which are now in Cygwin libm but used not to be)?

I.e., we should probably check for those functions Cephes provides (and Sage needs) [unless we're on FreeBSD where Cephes gets built anyway, or SAGE_PORT is set].

comment:21 in reply to: ↑ 20 ; follow-ups: Changed 7 years ago by jpflori

Replying to jpflori:

Replying to leif:

Replying to jdemeyer:

Replying to leif:

Actually, we need both sqrtl() and [lt]gammal() unless we build Cephes

It seems not, Cygwin doesn't have sqrtl(), nor does it build Cephes. Despite this, Sage builds.

IIRC, because we (still) have some special-casing on Cygwin w.r.t. at least (just?) the (long double) gamma functions.

I'll have a look.

Indeed, we cheat for logl/sqrtl/tgammal/lgammal in sage/symbolic/pynac_cc.h just as we do with the R patch for logl.


To repeat Karl-Dieter's question: What is Cephes then needed for at all [on e.g. FreeBSD]?

Maybe for complex functions "c*" (which are now in Cygwin libm but used not to be)?

I.e., we should probably check for those functions Cephes provides (and Sage needs) [unless we're on FreeBSD where Cephes gets built anyway, or SAGE_PORT is set].

comment:22 in reply to: ↑ 21 ; follow-up: Changed 7 years ago by jpflori

Replying to jpflori:

Replying to jpflori:

Replying to leif:

Replying to jdemeyer:

Replying to leif:

Actually, we need both sqrtl() and [lt]gammal() unless we build Cephes

It seems not, Cygwin doesn't have sqrtl(), nor does it build Cephes. Despite this, Sage builds.

IIRC, because we (still) have some special-casing on Cygwin w.r.t. at least (just?) the (long double) gamma functions.

I'll have a look.

Indeed, we cheat for logl/sqrtl/tgammal/lgammal in sage/symbolic/pynac_cc.h just as we do with the R patch for logl.

And as we only cheat on Cygwin, this implies Cephes is definitively needed on FreeBSD for this file already.


To repeat Karl-Dieter's question: What is Cephes then needed for at all [on e.g. FreeBSD]?

Maybe for complex functions "c*" (which are now in Cygwin libm but used not to be)?

I.e., we should probably check for those functions Cephes provides (and Sage needs) [unless we're on FreeBSD where Cephes gets built anyway, or SAGE_PORT is set].

comment:23 in reply to: ↑ 22 Changed 7 years ago by leif

Replying to jpflori:

Replying to jpflori:

Replying to jpflori:

Replying to leif:

IIRC, because we (still) have some special-casing on Cygwin w.r.t. at least (just?) the (long double) gamma functions.

Indeed, we cheat for logl/sqrtl/tgammal/lgammal in sage/symbolic/pynac_cc.h just as we do with the R patch for logl.

And as we only cheat on Cygwin, this implies Cephes is definitively needed on FreeBSD for this file already.

So what's your conclusion? (Regardless of perhaps cheating on FreeBSD as well.)


I.e., we should probably check for those functions Cephes provides (and Sage needs) [unless we're on FreeBSD where Cephes gets built anyway, or SAGE_PORT is set].

comment:24 Changed 7 years ago by jpflori

  • Description modified (diff)

In fact I slightly prefer the way things get printed with the second version of the reviewer patch. It's slightly easier to understand if both tar and make are missing. Feel free to change it back if you want.

comment:25 Changed 7 years ago by leif

P.S.: I don't have a strong opinion on the libm tests; building Sage requires a C99 environment (compiler + library) anyway. We may add a comment on this to the Sage Porting GuideTM.

comment:26 follow-up: Changed 7 years ago by jpflori

Replying to leif:

So what's your conclusion? (Regardless of perhaps cheating on FreeBSD as well.)

Don't really know. Check for sqrtl, logl, tgammal and lgammal everywhere except where:

  • we cheat, which is currently Cygwin,
  • we install Cephes, which is currently FreeBSD.

And if that fails, rant that supported platform should provide "long double" functions (except for the the two categories filtered out above) and suggest:

  • setting SAGE_PORT to something non-empty,
  • and:
    • either try installing the Cephes spkg,
    • or cheating as on Cygwin.

Both of these will be non-trivial anyway.

comment:27 in reply to: ↑ 26 ; follow-up: Changed 7 years ago by leif

Replying to jpflori:

Replying to leif:

So what's your conclusion? (Regardless of perhaps cheating on FreeBSD as well.)

Don't really know. Check for sqrtl, logl, tgammal and lgammal everywhere except where:

  • we cheat, which is currently Cygwin,
  • we install Cephes, which is currently FreeBSD.

And if that fails, rant that supported platform should provide "long double" functions (except for the the two categories filtered out above) and suggest:

  • setting SAGE_PORT to something non-empty,
  • and:
    • either try installing the Cephes spkg,
    • or cheating as on Cygwin.

+ * switch to another OS

+ Provide a link to the C99 standard.


Both of these will be non-trivial anyway.

Really?

comment:28 in reply to: ↑ 27 ; follow-up: Changed 7 years ago by jpflori

Replying to leif:

Replying to jpflori:

Replying to leif:

So what's your conclusion? (Regardless of perhaps cheating on FreeBSD as well.)

Don't really know. Check for sqrtl, logl, tgammal and lgammal everywhere except where:

  • we cheat, which is currently Cygwin,
  • we install Cephes, which is currently FreeBSD.

And if that fails, rant that supported platform should provide "long double" functions (except for the the two categories filtered out above) and suggest:

  • setting SAGE_PORT to something non-empty,
  • and:
    • either try installing the Cephes spkg,
    • or cheating as on Cygwin.

+ * switch to another OS

+ Provide a link to the C99 standard.


Both of these will be non-trivial anyway.

Really?

Depends on who tries it...

  • Cheating as on Cygwin is easy if you know where to look, although you should know a little bit of Sage to modify the R spkg, but I somehow agree it is not a long term solution, we don't want to patch every part of Sage which at some point will use "long double" functions... but then we can hope that Cygwin also include these functions in their libm, as they did for the "complex" functions, if every piece of software in the world need them.
  • Don't really know if installing Cephes just works out of the box, i.e. "oh I have a non-C99 compliant libm, let's just install cephes and every piece of Sage looking for C99 libm functions will find them now", that's surely the case but I've never tried.

comment:29 follow-up: Changed 7 years ago by jpflori

For Jeroen:

I guess we should check that the lapack (in fact its dependency liblapack0) and liblapack-devel packages are installed on Cygwin. In fact it should be enough to check the existence of the import libraries for libblas (and liblapack once we get #10508 in) as I do in the spkg-install file of ATLAS from #10508:

    libraries = ['/usr/lib/libblas.dll.a', '/usr/lib/liblapack.dll.a']
    for lib in libraries:
        if not os.path.exists(lib):
            print '*'*75
            print 'Could not locate required file: "' + lib + '".'
            print 'On Cygwin you must install the following standard LAPACK Cygwin packages'
            print 'via the Cygwin setup.exe program in the "Math" category:'
            print '* lapack,'
            print '* liblapack-devel.'
            print 'Alternatively you can try building your own ATLAS by setting'
            print 'SAGE_ATLAS_ARCH to something sensible although that is not'
            print 'officially supported.'
            print '*'*75
            sys.exit(1)

Modifying the spkg from #10508 so that it correctly builds will be slighlty non-trivial, or rather the way we include that in Volker's autotools stuff needs some thoughts.

comment:30 in reply to: ↑ 28 ; follow-up: Changed 7 years ago by jpflori

Replying to jpflori:

Replying to leif:

Replying to jpflori:

Replying to leif:

So what's your conclusion? (Regardless of perhaps cheating on FreeBSD as well.)

Don't really know. Check for sqrtl, logl, tgammal and lgammal everywhere except where:

  • we cheat, which is currently Cygwin,
  • we install Cephes, which is currently FreeBSD.

And if that fails, rant that supported platform should provide "long double" functions (except for the the two categories filtered out above) and suggest:

  • setting SAGE_PORT to something non-empty,
  • and:
    • either try installing the Cephes spkg,
    • or cheating as on Cygwin.

+ * switch to another OS

+ Provide a link to the C99 standard.


Both of these will be non-trivial anyway.

Really?

Depends on who tries it...

  • Cheating as on Cygwin is easy if you know where to look, although you should know a little bit of Sage to modify the R spkg, but I somehow agree it is not a long term solution, we don't want to patch every part of Sage which at some point will use "long double" functions... but then we can hope that Cygwin also include these functions in their libm, as they did for the "complex" functions, if every piece of software in the world need them.
  • Don't really know if installing Cephes just works out of the box, i.e. "oh I have a non-C99 compliant libm, let's just install cephes and every piece of Sage looking for C99 libm functions will find them now", that's surely the case but I've never tried.

I think that for the long term, especially if a lot of standard stuff we need use "long double" functions by default and provide no way of easily disabling their use (as R will do), the best solution would be to:

  • check for sqrtl (or any random "long double" function);
  • if that's not available, then set some SAGE_INSTALL_CEPHES variable which triggers the installation of Sage;
  • remove all the Cygwin "long double" hacks.

But please, let's do that later... For the moment, just:

  • check for sqrtl except on FreeBSD and Cygwin,
  • rant if not available, provide links to C99 standard, suggest the user to use a mainstream OS, invite him to have coffee or whatever (and maybe mention the fact that if he dares to set SAGE_PORT, then he could also try to manually install the cephes spkg when something fails because of the lack of "long double" functions).

comment:31 in reply to: ↑ 30 Changed 7 years ago by kcrisman

To repeat Karl-Dieter's question: What is Cephes then needed for at all [on e.g. FreeBSD]?

I don't recall asking about FreeBSD, simply stating that we do need it there. You can ask Stephen M-S about that on one of those ticket.

Indeed, we cheat for logl/sqrtl/tgammal/lgammal in sage/symbolic/pynac_cc.h just as we do with the R patch for logl.

However, I do invite someone to open a ticket to re-enable Cephes on Cygwin so that we can drop that entire file! If that is indeed the "right" solution.


But please, let's do that later...

Yes, please.

I guess we should check that the lapack (in fact its dependency liblapack0) and liblapack-devel packages are installed on Cygwin.

Oh, right. Good point, since #10508 is not yet in. But I was discouraged earlier from adding this to prereq, that's why I figured #10508 was better. I would definitely be in support of this being done on this ticket, and I've put something about that at #6743.

For the moment, just:

  • check for sqrtl except on FreeBSD and Cygwin,
  • rant if not available, provide links to C99 standard, suggest the user to use a mainstream OS, invite him to have coffee or whatever (and maybe mention the fact that if he dares to set SAGE_PORT, then he could also try to manually install the cephes spkg when something fails because of the lack of "long double" functions).

I think that some variation on this is very reasonable.

comment:32 in reply to: ↑ 29 ; follow-up: Changed 7 years ago by jdemeyer

Replying to jpflori:

we should check that the lapack [...] packages are installed on Cygwin

Why is it needed? I really don't like adding an extra check without understanding (and documenting) why.

Last edited 7 years ago by jdemeyer (previous) (diff)

comment:33 in reply to: ↑ 32 ; follow-up: Changed 7 years ago by kcrisman

we should check that the lapack [...] packages are installed on Cygwin

Why is it needed? I really don't like adding an extra check without understanding why.

Absolutely needed, because Sage ordinarily could build ATLAS/lapack spkgs on other systems but on Cygwin we (currently) need to have lapack already to get atlas to build things like R and Scipy, and it's not officially a prerequisite for Sage in general.

Unless I'm misunderstanding something about your question?

comment:34 follow-up: Changed 7 years ago by jdemeyer

I disagree with

if [ "$UNAME" = "SunOS" ]

comment:35 in reply to: ↑ 33 ; follow-up: Changed 7 years ago by jdemeyer

Replying to kcrisman:

Unless I'm misunderstanding something about your question?

You didn't really answer my question, you confirmed that it is needed without mentioning why it is needed. Perhaps a more explicit question is: what goes wrong if you don't have lapack?

comment:36 in reply to: ↑ 21 ; follow-up: Changed 7 years ago by jdemeyer

Replying to jpflori:

Indeed, we cheat for logl/sqrtl/tgammal/lgammal in sage/symbolic/pynac_cc.h just as we do with the R patch for logl.

I wouldn't mind always "cheating", i.e. not supporting logl() at all and drop all the Cygwin/FreeBSD hassle. Especially because long doubles don't have a portable meaning (they have a different precision on different systems).

comment:37 Changed 7 years ago by jdemeyer

I would be against more system-specific checks in prereq, I would like to move to a real ./configure before we do that. Because otherwise, it will lead to inconsistent checks (inconsistency between prereq and cephes's spkg-install like we're seeing now).

comment:38 in reply to: ↑ 34 ; follow-up: Changed 7 years ago by jpflori

Replying to jdemeyer:

I disagree with

if [ "$UNAME" = "SunOS" ]

I guess you been we should only

[ -f /usr/sfw/bin/* ]

? But will there really be anything else than SunOS where /usr/sfw/bin exists?

comment:39 in reply to: ↑ 35 ; follow-up: Changed 7 years ago by jpflori

Replying to jdemeyer:

Replying to kcrisman:

Unless I'm misunderstanding something about your question?

You didn't really answer my question, you confirmed that it is needed without mentioning why it is needed. Perhaps a more explicit question is: what goes wrong if you don't have lapack?

On Cygwin the lapack packages provide both BLAS and LAPACK. And the current Sage's ATLAS spkg, or the one from #10508, does not build ATLAS on Cygwin. It will not be really hard, but requires some more thoughts and work.

comment:40 in reply to: ↑ 38 Changed 7 years ago by jdemeyer

Replying to jpflori:

But will there really be anything else than SunOS where /usr/sfw/bin exists?

Assuming not, the check for SunOS is redundant anyway.

It all goes back to the philosophy of not checking the system, but checking features.

comment:41 in reply to: ↑ 39 ; follow-up: Changed 7 years ago by jdemeyer

Replying to jpflori:

And the current Sage's ATLAS spkg, or the one from #10508, does not build ATLAS on Cygwin. It will not be really hard, but requires some more thoughts and work.

OK, so it's a problem with the ATLAS spkg. In that case, would it not make more sense to add the check to the ATLAS spkg instead of prereq?

Changed 7 years ago by jpflori

comment:42 in reply to: ↑ 41 ; follow-up: Changed 7 years ago by jpflori

  • Description modified (diff)

Replying to jdemeyer:

Replying to jpflori:

And the current Sage's ATLAS spkg, or the one from #10508, does not build ATLAS on Cygwin. It will not be really hard, but requires some more thoughts and work.

OK, so it's a problem with the ATLAS spkg. In that case, would it not make more sense to add the check to the ATLAS spkg instead of prereq?

Its already there and provides info. I'm ok to not check anything in prereq and let the ATLAS spkg do the job (although the user might say "hey it passed prereq and now its asking for something more to be installed so much later!!!").

(And I just uploaded a new patch without redundant SunOS check.)

comment:43 in reply to: ↑ 36 ; follow-up: Changed 7 years ago by jpflori

Replying to jdemeyer:

Replying to jpflori:

Indeed, we cheat for logl/sqrtl/tgammal/lgammal in sage/symbolic/pynac_cc.h just as we do with the R patch for logl.

I wouldn't mind always "cheating", i.e. not supporting logl() at all and drop all the Cygwin/FreeBSD hassle. Especially because long doubles don't have a portable meaning (they have a different precision on different systems).

Ive got a slight preference for the SAGE_INST_CEPHES solution, espoecially it "could" be easier to maintain, but for the moment I could go with not even testing sqrtl anywhere assuming that its in the libm of supported platforms or were dealing with Cygwin or FreeBSD.

comment:44 in reply to: ↑ 42 Changed 7 years ago by jdemeyer

Reviewer patch is okay for me.

comment:45 in reply to: ↑ 43 ; follow-up: Changed 7 years ago by jdemeyer

Replying to jpflori:

Ive got a slight preference for the SAGE_INST_CEPHES solution

I don't really know what that "solution" would be.

The main thing I don't want is to spread the same checks in different places. For example, the lapack check should be either in prereq, either in ATLAS, not in both. Since it currently cannot be done only in prereq, it must be done in ATLAS.

comment:46 in reply to: ↑ 45 ; follow-up: Changed 7 years ago by jpflori

Replying to jdemeyer:

Replying to jpflori:

Ive got a slight preference for the SAGE_INST_CEPHES solution

I don't really know what that "solution" would be.

That would be:

  • check for sqrtl.
  • if not available trigger installation of the cephes spkg.

    The main thing I don't want is to spread the same checks in different places. For example, the lapack check should be either in prereq, either in ATLAS, not in both. Since it currently cannot be done only in prereq, it must be done in ATLAS.

comment:47 follow-up: Changed 7 years ago by kcrisman

Unless I'm misunderstanding something about your question?

You didn't really answer my question, you confirmed that it is needed without mentioning why it is needed. Perhaps a more explicit question is: what goes wrong if you don't have lapack?

On Cygwin the lapack packages provide both BLAS and LAPACK. And the current Sage's ATLAS spkg, or the one from #10508, does not build ATLAS on Cygwin. It will not be really hard, but requires some more thoughts and work.

I thought that was basically what I was saying... not sure what happened here.

Anyway, as to the check, the reason to have it early is that atlas might build quite late in a process, and then someone says "Oh, Mxyzptlk, why did I waste all that time building Sage and I didn't have the right prereqs?" Which I guess JP just said too.

comment:48 in reply to: ↑ 46 ; follow-up: Changed 7 years ago by jdemeyer

Replying to jpflori:

That would be:

  • check for sqrtl.
  • if not available trigger installation of the cephes spkg.

And how would a prereq check "trigger" the installation of the cephes spkg? I don't think that can currently be done.

comment:49 in reply to: ↑ 47 Changed 7 years ago by jdemeyer

Replying to kcrisman:

Anyway, as to the check, the reason to have it early is that atlas might build quite late in a process, and then someone says "Oh, Mxyzptlk, why did I waste all that time building Sage and I didn't have the right prereqs?" Which I guess JP just said too.

I certainly don't disagree with this, but for this to work (and also jpflori's idea of "triggering"), we need to change the prereq mechanism which is a lot less trivial than this ticket.

comment:50 in reply to: ↑ 48 ; follow-up: Changed 7 years ago by jpflori

Replying to jdemeyer:

Replying to jpflori:

That would be:

  • check for sqrtl.
  • if not available trigger installation of the cephes spkg.

And how would a prereq check "trigger" the installation of the cephes spkg? I don't think that can currently be done.

I thought we could do that just like you do for GCC. But that might be impossible, i did not check.

comment:51 in reply to: ↑ 50 Changed 7 years ago by jpflori

Replying to jpflori:

Replying to jdemeyer:

Replying to jpflori:

That would be:

  • check for sqrtl.
  • if not available trigger installation of the cephes spkg.

And how would a prereq check "trigger" the installation of the cephes spkg? I don't think that can currently be done.

I thought we could do that just like you do for GCC. But that might be impossible, i did not check.

Just a little more details of the way I see this, but that may be wrong:

  • at prereq time (or whenever the gcc version checks are done), set an env variable if the test fails (or the user can override it if he wants),
  • then either our spkg system is smart enough to build the cephes spkg iff this variable is set, or the spkg-install script from cephes spkg checks its value by itself and decide whether it should build or not (just like it now checks it is running on FreeBSD).

comment:52 Changed 7 years ago by jpflori

And I'm in for the idea of "let's postpone this complicated stuff" (for the ATLAS and Cephes stuff).

If nobody rants too loud, I'll put this ticket to positive review so that we have official "experimental" for Cygwin in 5.9 or 5.10.

comment:53 Changed 7 years ago by jdemeyer

Replying to jpflori:

I thought we could do that just like you do for GCC.

Not really, the check for GCC is done in spkg/install, not prereq.

I agree that all these checks should eventually move to a new file $SAGE_ROOT/configure, but that would require some refactoring of the build system. Since the Sage+GIT people are also refactoring the build system, it might make sense to wait for sage-6.1 to do this.

comment:54 Changed 7 years ago by jpflori

  • Authors changed from Jeroen Demeyer to Jeroen Demeyer, Jean-Pierre Flori
  • Reviewers set to Jean-Pierre Flori, Jeroen Demeyer
  • Status changed from needs_review to positive_review

Agreed, let's move on and merge this considering:

  • sqrtl is not really a prereq as it should be on all supported platform or provided either by cheating or by building cephes (and note FreeBSD is even not officialy supported). Later we can give it a similar treatment as GCC. We can wait for 6.1 to do this.
  • the ATLAS thing is currently only somehow boring on Cygwin, but the ATLAS spkg takes care of this (although later than the prereq one) and that is planned to change. For the moment what will happen is that ATLAS build will fail and tell the user to install the needed packages, he will do that and then the build process will go on. I guess someone actually trying to compile a huge thing as Sage can live with that. We should already wait for #10508 to be merged before doing that.

comment:55 Changed 7 years ago by jpflori

I've opened #14410 for the ATLAS on Cygwin stuff.

comment:56 Changed 7 years ago by kcrisman

Okay, this is better than the alternatives.

comment:57 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.9.beta4
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:58 follow-up: Changed 7 years ago by jpflori

Groumpf, I just realized that the last elif clause filtering OS names should include Cygwin (and beware that uname does not just return CYGWIN but CYGWIN... where ... gives additional precision which we don't really care about at the moment). Should we fix that on another ticket?

comment:59 in reply to: ↑ 58 Changed 7 years ago by jdemeyer

Replying to jpflori:

Should we fix that on another ticket?

Yes, I made #14447 but I'll let you write the patch.

As for the Cygwin version thing: I propose

if uname | grep CYGWIN >/dev/null; then
    ...
fi
Note: See TracTickets for help on using tickets.