nobody wrote on Monday, January 22, 2007:
could you please consider using libtool under unix. the advantage is that one can dload() glfw via foreign function interfaces (FFI) as they are present in Python 2.5, Common Lisp, Qu, Arena, etc. libtool also works with .dlls and makes including libraries at runtime platform independent. this is true for shared as well as for static libraries. libtool creates a .la database with meta-info about a static lib, which can be dloaded() as an extension to the already compiled-in .aout-file, so that the interfacing via the FFI is always the same for both shared and static libs.
elmindreda wrote on Sunday, January 28, 2007:
The 2.x build system probably won’t change very much, but the 3.x series will either use autotools or CMake. Not sure if what you need can be done with CMake, but I’ll find out.
nobody wrote on Friday, February 02, 2007:
I refuse using CMake (yet) because it’s not what it intends to be. It may be easier for programmers but users need to install and use it too so that this platform-specific-support-idea behind it is not visible to me as a user. If it would create config-files in addition to the makefiles…
I read that 2.6 wil install shared libs on all systems. This should already solve the above problem for me.
elmindreda wrote on Sunday, February 04, 2007:
Should I take that as a vote for using autotools?