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: https://bugs.call-cc.org/ticket/1644 Thanks! >> 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: http://wiki.call-cc.org/man/5/Using%20the%20compiler 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) N)) (module (the-module) () (import (only (chicken module) reexport)) (reexport (the-sub-module))) (module (the-program) () (import (the-module)) (the-func 123)) TIA -- Marco Maggi _______________________________________________ Chicken-users mailing list Chickenfirstname.lastname@example.org https://lists.nongnu.org/mailman/listinfo/chicken-users