[Top][All Lists]

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

Re: [Chicken-users] on generating types files for compound libraries of

From: Marco Maggi
Subject: Re: [Chicken-users] on generating types files for compound libraries of multiple modules
Date: Wed, 14 Aug 2019 11:06:15 +0200

Peter Bex wrote:

> On Wed, Aug 14, 2019 at 08:23:51AM +0200, Marco Maggi wrote:
>>   I see  there is  no declaration  specifier for  "-emit-types-file", is
>> there   a   reason?    I   would   appreciate   something   similar   to
>> "emit-import-library".

> I don't know, but it might be just a matter of nobody having had a use
> case yet.  I've made a ticket for this:


>>   Also: how do  you handle types files for shared  libraries composed by
>> multiple modules?   Should I generate a  types file for each  module and
>> install all of them along the shared library?  I doubt this is correct.

> No, as far as I know you simply load the types database using -types or
> -consult-types-file and that accepts any filename.  The core types
> database (types.db) also contains type information for several modules.
> So when you emit the types file you can just write it to a single file.

> Actually, I don't think there's even functionality in place to separate
> out the types per module.  So what you're trying to do sounds perfectly
> fine.

I  see that  the type  specifications in  the ".types"  files are  fully
qualified with the module name.  So there is a form of module-awareness.

>>   I have shared  libraries with multiple modules compiled  in.  Only one
>> module is the "public" one (exporting the public API), the others export
>> some "public" syntactic bindings  and some "private" syntactic bindings.
>> Is this case currently supported by CHICKEN?

> That should be fine.  It's not completely standard, so you might need to
> do a few things here and there to make it work, but I don't see any
> problem with it.  If you're running into specific problems, let us know
> and we'll try to find out what's going wrong.

Generation and use of these ".so"  shared libraries works fine.  I meant
this  relative  to the  types  declarations.   I  want to  exploit  this
documented behaviour (from "chicken type"):

   If library code is used with `import` and a `.types` file of the same
   name  exists   in  the   extension  repository   path,  then   it  is
   automatically consulted.  This allows  code using these  libraries to
   take advantage of type-information for library definitions.

  So,  for  now I  will:  generate  a  ".types"  file for  each  module;
concatenate  them  into  a  single ".types"  file;  install  the  global
resulting file along with the shared library.  Two questions:

1. Is  there a  way to print  to stderr the  list of  consulted ".types"
files?  I do not see such an option in:

2.   Let's assume  the  relevant  ".types" files  are  loaded; with  the
following pseudo code:  is the type specification of  "the-func" used by
the program?

(module (the-sub-module)
  (import (scheme) (chicken type))
  (: the-func (fixnum -> fixnum))
  (define (the-func N)

(module (the-module)
  (import (only (chicken module) reexport))
  (reexport (the-sub-module)))

(module (the-program)
  (import (the-module))
  (the-func 123))

Marco Maggi

reply via email to

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