Hendrik Boom wrote on 8/24/19 8:48 AM:
The only problem I see is with the ue of macros in the propietary part of your software. They make it difficult to take your object code and link it with revised versions of the LGPL'd Racket code.
This seems much the same problem as doing the analogous thing with C libraries, not unique to Racket.
Racket macros in practice tend to do than C macros do, but the sensitivity of the mechanism seems much the same.
For example, if a C header changes even a single simple cpp-based `#define SOME_VALUE 7` "constant" between versions, that would probably get baked into compiled code, and one would probably be incorrect to relink (without recompiling) a new version of the library that changed that.
(Incidentally, the drawbacks of mixing in closed binary libraries and kernel modules with open source software are well-known in C and C++. This might plague you, for example, if you're trying to bring up new Linux on an old Linux-based device that used closed drivers, or are dependent on Nvidia closed drivers for your video display or your GPU compute engines. Separate from not being able to inspect and improve the closed stuff, they tend to eventually stop working with newer software with which they link, with no practical recourse.)
-- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/277e5d62-b94b-e639-a6e8-f49ff43a58da%40neilvandyke.org.
