Greg: > So in other words, this would be a use of the fla lib without > fltk? ie. being able to use the fla code from a pure C program > on an embedded platform that doesn't have C++ at all, implying > a non-fltk program?
Stand alone or with (hopefully at some point) a basic FLTK C widget set. Greg: > So this might almost be its own subproject, with its own > docs on how to use it from application code without fltk? We are planning to document the interface for both FLTK and stand alone use. However, we would still consider it a lower level FLTK. The wrapper would be included with the idea that it provides a good foundation for building widgets. Greg: > What many found is that if you release two files that depend on > each other (execs + dll/so's), end users will find fascinating ways > of separating them that are sometimes really hard to troubleshoot. We are very familiar with this issue too. I don't see why a monolithic lib build wouldn't be possible. We also take some measures that aim to limit this exposure. We always export so/dll version/signature calls and require the lib to be in a specific location relative to the application. We use what we call "direct loading". This is loading the lib by specific path/name and taking the system lib path out of the equation. In this scenario the app won't/can't load an incompatible lib unless the dev/build screws up by signing and shipping an incompatible lib. Thanks, Gerry _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
