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 -- 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.
