Sorry for my silence, however I've got a weird problem this week. My modem has burnt ! So I think I'm a bit "Maudit des couilles", I think Alex can translate easily this nice french touch ;).
So I was disapointed, and it is why I've not touched my computer since this crash ! So I'm back again, and I'll try to take a look at the stuff you have done this week-end ;) > On 9/28/06, Alexandre Courbot <[EMAIL PROTECTED]> wrote: > > Still, it'd be interesting to list what is missing before we can > > consider cmake as ready for "production". I've been noticing the > > following things: > > > > - Dynamically-loaded libraries are named libsomething.so instead of > > something.so (e.g. libsdl.so instead of sdl.so), > > - Python wrappers are not installed, > > - Versions of installed libraries/tools should be checked by cmake. > > - linker flags missing on OS X: -Wl,-undefined suppress > -Wl,-flat_namespace; maybe others > - data directory should be detected automatically, depending on system arch > - linking on Win32 fails with undefined references ... need to dig in > further, but it might be the case that for a dll, all symbols must be > available when the dll is created. Maybe my suggestion will be stuppid, however I think on windows we need to explicit export symbol ? Right ? So it's why when one try to build a dll it use the __delspec keywork, isn't it ? #ifdef WIN32 #ifdef ADONTHELL_GFX_EXPORTS #define ADONTHELL_GFX_API __declspec(dllexport) #else #define ADONTHELL_GFX_API __declspec(dllimport) #endif #else /* WIN32 */ #export ADONTHELL_GFX_API #endif So when we compile the GFX part, we have to pass to the compiler the -DADONTHELL_GFX_EXPORTS And by example for a class inside the gfx part. namespace adonthell { namespace gfx { class ADONTHELL_GFX_API surface { ... }; } } Maybe i've missed something, but when one tries to play with windows DLL, we to do something like that. I wait your comments, Jol > That's not an issue of cmake > though, didn't work with autotools either. Maybe, there's a linker > flag like on OS X to get it working, otherwise some changes to the > order of compilation and libs linked have to be made. > > > I'm excited about cmake, so maybe I can look at these issues and try > > to fix them, for my cmake culture. However, if Joel is still working > > on it, I'd rather let him do and learn by watching the final result. > > I'll see whether I can fix the OS X and Windows issues, but I try to > not touch general stuff like version checking or properly installing > and naming stuff. > > Kai > > > _______________________________________________ > Adonthell-devel mailing list > Adonthell-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/adonthell-devel _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel