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.

Reply via email to