Hello there, I now have a graphviz-guile package with a graphviz.scm module file.
Where should I link/copy/move libgv_guile.so? I tried: $PACKAGE_OUTPUT/lib/ $PACKAGE_OUTPUT/lib/guile/2.0/ $PACKAGE_OUTPUT/lib/guile/2.0/extensions/ But it seems my system only looks in: /lib /gnu/store/...-gcc-4.9.3-lib/lib/ /gnu/store/...-glibc-2.22/lib/ /gnu/store/...-guile-2.0.11/lib/ Kind regards, Roel Janssen Roel Janssen writes: > Hello Danny, > > Thank you for your elaborate response. This makes it quite easy for me > to write the module file. I added "write" and "rm" to the module, which > should make it complete. > > What is the preferred way to include the module file to the package? > Should I create another package with this file alone, and use it as a > propagated input for graphviz? > > Kind regards, > Roel Janssen > > > Danny Milosavljevic writes: > >> Hi, >> >> On Mon, 09 May 2016 22:54:00 +0200 >> Roel Janssen <r...@gnu.org> wrote: >> >>> it is automatically generated using SWIG. I had to experiment a bit to >>> find out that the functions exposed in Guile did not have a namespace (gv.). >> >> You can add a prefix when importing, so the symbols of the module shouldn't >> have a prefix - the user would end up with two prefixes (or would have to >> cut the other prefix out and replace it or something). >> >> (use-modules ((gdb) #:renamer (symbol-prefix-proc 'gdb:))) >> >> See also <http://www.swig.org/Doc2.0/Guile.html>. >> >>> There are functions called "rm" and "write" which are obviously already >>> used for other purposes in Scheme. These functions will have to be >>> renamed or just left out of the Scheme module. >> >> The user can specify which symbols to import (and also rename stuff there if >> needed) so I'd do nothing of the sort. >> >> (use-modules ((ice-9 popen) >> #:select ((open-pipe . pipe-open) close-pipe) >> #:renamer (symbol-prefix-proc 'unixy:))) >> >> It's true that people still use the form >> >> (use-modules (xxx)) >> >> without specifying what the final imported symbols are, but that's something >> I consider bad practise in most cases (in any language - hey let's import >> random stuff into my namespace and have which module it gets each function >> from change on each package update. How about no?). >> >> For example, let's say you have two modules "a" and "b". >> Let module "a" contain "select". >> Let module "b" contain "write". >> >> Let's say you use it as >> >> (use-modules (a) (b)) >> >> ; main program >> (write ...) >> (select ...) >> >> Then it will use b's write, a's select in your program, repectively. Say you >> release it and people use it. >> >> Now let's say someone devious (not really, it can make sense to him) adds >> "select" to module "b". Suddenly your program will use b's select *even >> though you didn't change anything in it*. >> >> Bad. >> >> A complete set to try this: >> >> $ export GUILE_LOAD_PATH=. >> >> ;;; a.scm >> (define-module (a) #:export (select)) >> (define (select) (display "a.select") (newline)) >> >> ;;; b.scm >> (define-module (b) #:export (write select)) >> (define (write) (display "b.write") (newline)) >> (define (select) (display "b.select") (newline)) >> >> ;;; main.scm >> (use-modules (a) (b)) >> (write) >> (select) >> >> Note that you do get warnings by guile >> >> WARNING: (guile-user): imported module (a) overrides core binding `select' >> WARNING: (guile-user): `select' imported from both (a) and (b) >> b.select >> WARNING: (guile-user): imported module (b) overrides core binding `write' >> b.write >> >> ... which is nice.
