gforth
[Top][All Lists]
Advanced

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

Re: [gforth] Configuring multiple libccdirs


From: Reepca Russelstein
Subject: Re: [gforth] Configuring multiple libccdirs
Date: Tue, 3 Jul 2018 20:54:42 -0500

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 <address@hidden> 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;address@hidden(dQ*
> https://net2o.de/



reply via email to

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