GNU bug report logs - #18033
Add support for 'search-path-specifications' referring to files

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: 18033 <at> debbugs.gnu.org
Cc: John Darrington <jmd <at> gnu.org>
Subject: bug#18033: Add support for 'search-path-specifications' referring to files
Date: Wed, 16 Jul 2014 16:02:20 +0200

See use case below.

John Darrington <john <at> darrington.wattle.id.au> skribis:

> On Wed, Jul 16, 2014 at 11:23:12AM +0200, Ludovic Court??s wrote:
>      John Darrington <john <at> darrington.wattle.id.au> 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'

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.