bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18033: Add support for 'search-path-specifications' referring to fil


From: Ludovic Courtès
Subject: bug#18033: Add support for 'search-path-specifications' referring to files
Date: Wed, 16 Jul 2014 16:02:20 +0200
User-agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)

See use case below.

John Darrington <address@hidden> skribis:

> On Wed, Jul 16, 2014 at 11:23:12AM +0200, Ludovic Court??s wrote:
>      John Darrington <address@hidden> skribis:
>      
>      > On Tue, Jul 15, 2014 at 10:59:17PM +0200, Ludovic Court??s wrote:
>      
>      [...]
>      
>      >      The problem is that ???search-path-specification??? is meant for 
> $PATH-like
>      >      variables that list directories, not files.
>      >
>      > That occurred to me too.  But what problems does it actually cause?
>      
>      That we can???t use it for $XML_CATALOG_FILES.
>      
>      >      So I see two solutions:
>      >      
>      >        1. Patch libxml2 so that it honors a new variable, say
>      >           $XML_CATALOG_DIRECTORIES, which would allow us to use
>      >           ???search-path-specification???.
>      >      
>      >        2. Augment support for search paths to allow file-based search 
> paths.
>      >      
>      >      (2) may be best in the long run, but it has ramifications in 
> different
>      >      places.
>      >      
>      >
>      > (1) seems like a good idea only if upstream can be persuaded to adopt 
> it.
>      
>      Which is unlikely, given that it???s redundant with $XML_CATALOG_FILES.
>      
>      > What are the ramifications of (2) ?
>      
>      There are changes in the build tools, for instance 
> ???search-path-as-list???
>      (used by ???set-path-environment-variable???, used in 
> gnu-build-system.scm)
>      expects directories, not files.  And all this calls things
>      ???directories???.
>      
>      This is a change we could schedule for the next core-updates.
>
> This sounds like it is the most sensible solution. 
>
> J'





reply via email to

[Prev in Thread] Current Thread [Next in Thread]