Hi Anton
I think I may understand what you're thinking about: if usocket was compiled first by pushing :usocket-iolib, then if we start a clean Lisp environment and do (asdf:load-system :usocket) without having the same keyword in *features*, then the loading of compiled FASLs will fail.
Among all those famous ASDF-based packages, I see hunchentoot also used the same approach to compile a special version with SSL support: by pushing :hunchentoot-no-ssl into *features*, hunchentoot can be compiled successfully on platforms (like the old MCL) where CL+SSL is not available yet, or when user simply don't need SSL for their web servers.
To solve all related issue, I'm going to do some runtime detection on *features*: if last compile time usocket was compiled with or without :usocket-iolib but current load time the feature set is different, ASDF should re-compile all usocket source files instead, not just load previous FASLs. (I'm not sure if ASDF have already provided such a feature, so let me also copy this mail to Faré, the ASDF maintainer)
I don't like the idea of creating a whole new ASDF system like "usocket-iolib", because that will require other packages to change their system definitions to benefit from this new work. And the most important thing, whether to depend on IOlib is totally an internal fair of usocket: it doesn't change the programming interface at all. And the choice on if user want to use native network support of IOlib-based network support on their current platforms, ONLY depends on if they like to load additional DLLs (by CFFI). I always want usocket to depend on nothing, so that we can easily patch those 24x7 lisp servers to upgrade the networking support smoothly.
Let me know if you have other concerns. Thanks.
Regards,
Chun Tian (binghe)
On 24/giu/2013, at 17:12, Anton Vodonosov avodonosov@yandex.ru wrote:
Hello.
24.06.2013, 11:22, "Chun Tian (binghe)" binghe.lisp@gmail.com:
To compile usocket with IOlib, user should push :usocket-iolib into their *feature* first.
I would like to propose to use some other solution than conditional controlling compilation with *reatures*.
The disadvantage of the conditional compilation is that when my application loads the usocket as a dependency, the application doesn't know how usocket will work, because it was dediced when usocket was compiled (possible during load of some other application).
If you give little bit more details about he usocket-iolib functions, I can propose more concrete solutions. Very possible the proposal will be a separate ASDF system, usocket-iolib.
Best regards,
- Anton