It looks that this is a general issue, about which I do not know enough (yet) to contribute usefully, and which largely surpasses the R update issue I was tackling.
Therefore, I suggest to treat the latter, lesser issue in the current framework (i. e. no conditional installation for package), and consider overhauling this framework as a more general problem. -- Emmanuel Charpentier Le mercredi 26 octobre 2016 15:16:31 UTC+2, Jean-Pierre Flori a écrit : > > > > On Wednesday, October 26, 2016 at 3:01:48 PM UTC+2, Jean-Pierre Flori > wrote: >> >> >> >> On Wednesday, October 26, 2016 at 2:58:44 PM UTC+2, Jean-Pierre Flori >> wrote: >>> >>> >>> >>> On Wednesday, October 26, 2016 at 2:22:45 PM UTC+2, Jean-Pierre Flori >>> wrote: >>>> >>>> >>>> >>>> On Wednesday, October 26, 2016 at 2:08:25 PM UTC+2, Emmanuel >>>> Charpentier wrote: >>>>> >>>>> >>>>> >>>>> Le mercredi 26 octobre 2016 13:40:14 UTC+2, Jean-Pierre Flori a écrit : >>>>>> >>>>>> It would be great to let the user choose when to use system libraries >>>>>> instead of building our own, whether its curl or gmp. >>>>>> A problem coming to my mind to have a simple >>>>>> --with-curl=[system|build] working. >>>>>> >>>>> >>>>> That means, if I follow you, to have to patch each and every >>>>> (candidate) package potentially using curl in order to consider this >>>>> flag. >>>>> Not exactly low-maintainance... >>>>> >>>> What do we gain ? >>>>> >>>> I don't get you. >>>> >>>> The current situation is that for every package built by Sage depending >>>> on any other package built by Sage, we have to tell them to look into >>>> $SAGE_LOCAL for including headers and linking to libraries. >>>> >>>> I suggest to add a --with-curl=... or --with-systemwide-pkgs=... option >>>> to the toplevel configure of "Sage the distribution" to tell "Sage the >>>> distribution" not to build its own curl but to rely on a system wide one. >>>> But then we have to tell each package built by "Sage the distribution" >>>> to look for its dependencies either in $SAGE_LOCAL (which is basically >>>> always the case at the moment) or in standard system-wide paths (hopefully >>>> we won't support non standard paths in the near future). >>>> >>>> So we indeed need to modify the configure options in each spkg-install >>>> scripts of pkgs depending on curl to have "--with-curl=`pkgconfig >>>> --blablbabla`" or anything sensible which would tell it to either look >>>> into >>>> $SAGE_LOCAL or in default paths. >>>> The only other way to do this without passing stuff to configure >>>> scripts of each package is playing with LDFLAGS and CFLAGS and this has >>>> unfortunately less chances of success than using configure scripts >>>> options, >>>> good luck with that. >>>> >>>> >>>>> Furthermore, that introduce the possibility of having *simultaneously* >>>>> some packages using our version of curl and others using system's >>>>> version. >>>>> Ouch... >>>>> >>>>> Yes maybe. >>>> I can surely make it so that Sage gets both ATLAS and openblas >>>> installed if I really want to and link to both of them in a random way. >>>> >>>> A more consistent way would be to pass a flag to curl's installation >>>>> script telling it to fake installation or to force build. That is >>>>> possible, >>>>> but, again, not very consistent with the primitive idea of enforcing some >>>>> consistency. >>>>> >>>> No it does not solve the issue of packages having to link to libcurl. >>>> Unless you want to play with LDFLAGS and C[...]FLAGS rather than >>>> passing options to configure scripts of these packages. >>>> >>> In fact you still have to deal with LDFLAGS and CPPFLAGS. >>> At least R only looks in what they define and you cannot give anything >>> through a --with-curl= option. >>> >>> By the way it seems that Sage modifies by default LDFLAGS globally to >>> include $SAGE_LOCAL/lib but not CPPFLAGS. >>> >> >> Maybe we can use config.site as well: >> >> https://www.gnu.org/software/automake/manual/html_node/config_002esite.html >> > > We set CPATH, but I'm not sure it is enough for autotools. > -- 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.