I have no opinion on whether this approach is on the whole a good idea, but I will point out that "which curl" is not as portable as "command -v curl". We had an issue a while ago with "which" not behaving properly on some platform -- maybe on Solaris "which blah" had a return status of 0 even if "blah" was not present? I forget. Anyway, if nothing else, try "command -v ..." instead of "which ...". (And would it be even better to try to run curl to make sure it functions properly, instead of just seeing if it's present?)
John On Tuesday, October 25, 2016 at 2:52:34 PM UTC-7, Emmanuel Charpentier wrote: > > This is now Trac#21767 <https://trac.sagemath.org/ticket/21767>. The > unconditional installation works okay on top of 7.5beta0. > > The conditional installation can probably be obtained with this bash > snippet, at the top of spkg-install : > > ## Installation de curl... > > ## Look for a systemwide installation > > LibExists=no > if $(pkg-config --exists libcurl) ; then > LibExists=yes > echo A systemwide version of libcurl exists. Testing it. > else > echo "No systemwide curl installation (or not using pkg-config)." > fi > > ## Systemwide installation version check > > VersOK=no > if test $LibExists = yes ; then > if ! test "7.28.0" ">" $(pkg-config --modversion libcurl) ; then > echo Systemwide installation of libcurl is enough to support R. > VersOK=yes > else > echo Systemwide version of libcurl too old to support our R. > fi > fi > > ## Checking for a systemwide executable > > ExecOK=no > if test $VersOK = yes ; then > if test X$(which curl)X = XX ; then > echo No systemwide curl executable in PATH. > else > echo Systemwide curl executable found. > ExecOK=yes > fi > fi > > if test $ExecOK = yes ; then > echo No local installation required. > exit 0 > else > echo Starting curl installation... > fi > > The same tachnique can probably been used for xz. pcre will need a > supplemental step (checking configuration). > > What do you think ? > > -- > Emmanuel Charpentier > > Le mardi 25 octobre 2016 11:15:56 UTC+2, Jean-Pierre Flori a écrit : >> >> >> >> On Tuesday, October 25, 2016 at 11:11:38 AM UTC+2, Jean-Pierre Flori >> wrote: >>> >>> >>> >>> On Tuesday, October 25, 2016 at 12:48:39 AM UTC+2, Dima Pasechnik wrote: >>>> >>>> >>>> >>>> On Monday, October 24, 2016 at 9:45:18 PM UTC, Emmanuel Charpentier >>>> wrote: >>>>> >>>>> Okay. I I have followed you correctly, we have two (mutually >>>>> incompatible) options : >>>>> >>>>> >>>>> - (Dima's option) : package curl, pcre and xz as standard >>>>> packages, and make R depend on them (unconditionnally). >>>>> - (Jean-Pierre option) : add tjem to Sage's core, but build them >>>>> if and only if they are not installed systemwide (= useable at Sage's >>>>> compile time) ; do this before trying to build R. >>>>> >>>>> The first option is extremely simple and failsafe. The cost is about >>>>> 15 MB (sum of all installed files in a temporary "prefix" directory, >>>>> without shaving anything) and about 3 minutes of compilation time (no >>>>> parallelism used). We might shave 4,9 MB of docs (local/share/(doc|man). >>>>> Binaries are about 0.9MB. The total potential cots (sum of sizes of the >>>>> three build directories) is 89 MB (= potential cost if the three build >>>>> directories ate kept after building i. e. for debugging purposes). >>>>> >>>> >>>> I don't really follow you: note that gcc is also a standard package, >>>> but it only really gets installed if the system gcc is >>>> not good enough. That is to say, if curl, pcre, and xz are available >>>> system-wide, Sage should not try to install them, >>>> no megabytes used... >>>> >>> I don't think the real issue is megabytes, but rather making sage more >>> modular and easier to ship into distributions (other than sage-the-distrib). >>> >>> >>>> >>>> >>>>> >>>>> The second one requires hacking the main Sage configuration. I do not >>>>> feel currently quite at ease with this one, but I'm just reading the >>>>> relevant docs. I have no idea of the potential costs, save for what can >>>>> be >>>>> deduced from the costs of Dima's options. >>>>> >>>>> The first option is compatible with the "batteries included" >>>>> philosophy flaunted by Sage. are the potential 10-15 MB savings worth of >>>>> hacking the main Sage config file ? >>>>> >>>> You can already add them as standard packages and then we can work on >>> making them installed only if not available system-wide. >>> These two steps can be done sequentially though it would be better to >>> get the two of them at the same time. >>> >> If you open a tcket with the first step, I'll do the second one, and >> Jeroen or someone else can review it. >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
