> > I can't say that I like this design decision, but I guess I'll have to > live with it. If this is unsupported, it also feels strange that > the .egg format allows specification of multiple import libraries per > extension at all – the provider side of the picture, when you write a > library with multiple modules, is supported, but the consumer side, > when you try to use it, is suddenly not supported any longer.
I'm not sure what you mean, some example would be helpful here. > > You also suggest that separating load and import is possible when done > "manually", but I couldn't find any information on how one would > approach that. Could you elaborate this "manual" approach a little bit? The low-level forms for loading/linking are still available (uses, load-library), it's the high-level view that has changed. > $ cat foobar.egg > ((components > (extension foobar > (modules (foo bar))))) > > $ chicken-install -n > building foobar > [...] > /opt/chicken/bin/csc -setup-mode -s -host -I /home/murphy/foobar -C > -I/home/murphy/foobar -O2 -d0 /home/murphy/foobar/(foo bar).import.scm > -o /home/murphy/foobar/(foo bar).import.so csc: file > `/home/murphy/foobar/(foo bar).import.scm' does not exist Sure, that should indeed be handled. I'll fix this. > > Yes, use a custom build script. I'm working on a way to handle the case of > > separate > > ..c files that need to be linked. Due to how we support static linking this > > is > > not trivial. > > [...] > > How about producing .a / .lib files instead of .o files for static > linkage – wouldn't that simplify including multiple compilation units? It would, but would complicate other cases. You need different tools on different platforms, need run ranlib(1) on installed .a's on MacOS, and so on. It's certainly one way of doing this, but we already support .o files. Patches are welcome, of course... felix _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
