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