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.
