Re: Configuring multiple libccdirs

Reepca Russelstein <[email protected]>
Newsgroups gmane.comp.lang.forth.gforth
Message-ID <CA+jmvS7XD6i0kLgThGmCik8v=H2vY4Nqj-pWYXsyYP+tpbSWCQ@mail.gmail.com>
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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.