I suppose I should give a concrete example: I am attempting to write some interfaces to various C libraries - for example, cpython and glfw. I've generated some interfaces with forth-enabled swig before, but I can't install them separately from gforth itself as guix packages because there isn't a version-independent directory to put the wrappers in, and I'd have to re-hardcode it for every version change (and I update my gforth package from git, so "version change" is pretty frequent, as it includes the date). Currently I just have a gforth-kitchen-sink package where I put all the wrappers I could possibly want and install that, but I have to use a modified version of the source for it. Also, the way the guix build process works, I can't install a package output to anything in a home directory - installation happens to a store item, the store items installed for a user are unioned and built into a profile, and that profile is symlinked from ~/.guix-profile.
There's also the issue of architecture-specific directories - I'm not sure how to write a package that could change an environment variable specification based on the target architecture, since that isn't known at package-definition-time. This could all be made to work by letting an environment variable specify more than one directory to search for compiled wrappers in. GFORTHCCPATH sounds agreeable to me, though I do wonder if it would work just as well to search for both forth source and compiled wrappers in GFORTHPATH. On Tue, Jul 3, 2018 at 3:01 PM, Bernd Paysan <[email protected]> wrote: > Am Dienstag, 3. Juli 2018, 18:05:21 CEST schrieb Anton Ertl: >> 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. > > Actually, the libcc API has stabilized, and the need to recompile the libcc > interfaces for every Gforth snapshot isn't there anymore. > > So it makes sense to install programs with precompiled libcc-named files, and > keep them separate from the Gforth directory, which is updated every week or > so (if they use my snapshot Debian repository). > >> 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? > > As I can see the request, for third-party programs using Gforth as Forth > engine, who want to install their files in a different directory. The source > files installed in some other directory can be dealt with GFORTHPATH, the > libcc-named files installed not — they have to go to a version specific Gforth > directory. > > We can also discuss if we add the $prefix/lib/.../site-forth path into the > libcc-path by default. > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself" > net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* > https://net2o.de/
