On Tue, Jul 03, 2018 at 04:34:34PM +0200, Bernd Paysan wrote: > Am Dienstag, 3. Juli 2018, 12:03:57 CEST schrieb Reepca Russelstein: > > Currently there are two places gforth will check for already-existing > > compiled wrapper code: > > > > 1. ~/.gforth/<machine-type>/libcc-named > > 2. $libccdir or, if that isn't set, the value of $libccdir at the time > > gforth was compiled. > > > > This presents an issue if we have wrapper code we want to go somewhere > > else and want gforth to still be able to find its own wrapper code - > > we can't set libccdir for this purpose. For example, if I want to > > install a separate package that provides wrapper code - maybe I'll > > call it gforth-glfw - I'd want to put it in > > PREFIX/lib/gforth/site-forth/libcc-named. > > > > Could we change libccdir to specify a search path instead of a single > > directory, with build-time $libccdir implicitly prepended to that > > path? > > Yes, that's easy to do. I would suggest however to keep libccdir as is, and > add a GFORTHCCPATH the way you want to. Public visible environment variables > controlling Gforth should be in uppercase and have a GFORTH in their name.
The question is if it makes sense. The files in these directories are cached intermediate results produced from Forth source files containing C-interface stuff. We have two directories for the following reasons: 2) $libccdir for files created by the superuser at Gforth installation, so the user does not need a C compiler when using the source C-interface files; it also allows sharing these files between different users, without one user being able to attack another user by providing a Trojan intermediate file. 1) For C-interface stuff beyond libccdir, each user produces his own intermediate files in ~/.gforth/<machine-type>/libcc-named. For what purpose would one use more directories? - anton
