Same DLL-String for all OS in the scheme file

[Blakharaz]

It would be nice (and surely almost no effort implementing it) to have the same names for the loaded DLLs in the scheme XML file for all OS, now there is the whole name of the loaded DLL which is like "Taharez Look.dll" in Windows and "libCEGUITaharezLook.so" in Linux, so you need different scheme files for projects that are for both platforms.
It should be a string like "TaharezLook" and the program decides the exactly name of the DLL to load.

[CrazyEddie]

Yep, this is being put in for beta-1, and should be functional by next week.

CE.

[_mental_]

CE, let me know if you need a hand with the Linux portion of this. It maybe a good idea to consolidate the library loading routines at the same time like we do with OGRE.

[CrazyEddie]

Yeah, that would be cool

What type of thing did you have in mind here?

[_mental_]

We could use something like libltdl. From the libltdl README:

Code: Select all

This is GNU libltdl, a system independent dlopen wrapper for GNU libtool.

It supports the following dlopen interfaces:
* dlopen (Solaris, Linux and various BSD flavors)
* shl_load (HP-UX)
* LoadLibrary (Win16 and Win32)
* load_add_on (BeOS)
* GNU DLD (emulates dynamic linking for static libraries)
* dyld (darwin/Mac OS X)
* libtool's dlpreopen


libltdl is under the LGPL The catch is that there isn't a VC project for it.

The other option is to do something like we did for OGRE (OgreMain/include/OgreDynLib.h has the details) which you have a compile time define to set the appropriate library load, unload and getprocaddress depending on the system.

This way we can get rid of the individual implementation files.

[RuprechtTheMonkeyBoy]

It's funny that you guys mention this, because I was getting ready to suggest the very same thing. I had just finished adapting the library loader to work on Mac OS X to use ".bundle" with just the base name in the XML file. In fact, I borrowed the code from OGRE to do it, so it was very easy (thanks temas!)

[CrazyEddie]

Yeah, you drew my attention to libltdl before, which is when we discovered that VC has problems... Anyway, what I'll do is take another look at that later today and see if that problem can be fixed, else we'll just steal some code from Ogre

[CrazyEddie]

I have successfully compiled and tested libltdl under vc, so this is likely now the best way to go

I'm sure there's still a couple of issues to consider regarding names and what have you, but at least if we can now use libltdl the solution will be unified for all platforms.

CE.

[RuprechtTheMonkeyBoy]

I'm sure there's still a couple of issues to consider regarding names and what have you, but at least if we can now use libltdl the solution will be unified for all platforms.

The widget set libraries are the ones that will be primarily used by this functionality, yes? If this is so, are they intended to be distributed with the application or with the CEGUI library(ies)?

The reason I ask is because (at least on OS X) it seems to make more sense to build them as bundles that are resources of the CEGUI framework. This allows the syste to do the grunt work of finding and loading the bundle. But this would mean sticking with a platform-specific implementation of library loading.

If you go with libltdl, it doesn't make any assumptions about the location of the library, so on OS X, if the library isn't included as part of the app (which would know where to find it), there will still need to be some platform-specific implementation to search for the library's location.

If the CEGUI framework/libraries are meant to be distributed with a compiled app, then finding/loading the widget set library might still be an issue, since it makes the most sense on an OS X app to include them inside the application's bundle, which a platform-agnostic loader wouldn't know about.

(I might be missing a simpler solution, but this is what occured to me when thinking about libltdl vs. platform-specific library loading implementation.)

Hope I'm not rambling... Anyway, IMHO, I think it would probably be better to stay with platform-specific implementations of library loading. Just my $.02.

In any case, once the details are worked out, I can make any necessary changes to the Xcode project for CEGUI.

[CrazyEddie]

@RuprechtTheMonkeyBoy:
The widget modules should really part of the app rather than part of the library. It's possible to for users to do all kinds of funky stuff by writing their own widget modules so these are definately more an app thing. (By this I do not mean that to write a widget module you have to implement all the widgets. One small example would be to code a module containing a single widget, and use the scheme system to effectively replace a widget in the supplied Taharez and Windows look modules with something custom built; then any use of the widget would use the custom one instead).

Now I'm not entirely sure what to do for the best Currently, the modules are loaded by specifying a path relative to the main executable anyway, so there is, in effect no real searching going on. I don't know how this relates to things on OS X


@Guest:
The problem with this suggestion is that it breaks down if the user writes a module and does not use the same naming convention (who am I to tell the user what they should name their module?). Having said this, it would solve a couple of annoyances I've been having while playing around with adding the _d to the files as suggested by Blakharaz

CE.

[RuprechtTheMonkeyBoy]

@RuprechtTheMonkeyBoy:
The widget modules should really part of the app rather than part of the library. It's possible to for users to do all kinds of funky stuff by writing their own widget modules so these are definately more an app thing.

Excellent.

Now I'm not entirely sure what to do for the best Currently, the modules are loaded by specifying a path relative to the main executable anyway, so there is, in effect no real searching going on. I don't know how this relates to things on OS X

In a nutshell, an OS X app looks like this on the filesystem:

Code: Select all

<appname>.app
+--Contents
   +--MacOS
      +--<appname> (this is the executable)
   +--Resources (this directory contains loadable bundles/libraries, images, etc.)
   +--Frameworks (this directory contains distributed frameworks/libraries, like CEGUI, Ogre, SDL, etc.)


The end user sees "<appname>.app" as just "<appname>" on the desktop, and executes it like it's a single program file.

The widget libraries (or bundles on OS X) would live in the Resources directory. So all the library needs to do is ask the system where its resources are and load the appropriate bundle. (Currently, the OS X loader code for CEGUI asks for the resources directory relative to the CEGUI framework, but it's simple to change it to ask for the app's resources, or perhaps a sequential search, say, first the app's resources, then the framework's resources.)

[CrazyEddie]

Thanks for the explanation Where does this leave us with regards to libltdl?

CE.

[RuprechtTheMonkeyBoy]

Thanks for the explanation Where does this leave us with regards to libltdl?

It's possible to use it, but it will still require some platform-specific code on the Mac to look up the path to the Resources directory.

IMHO, if you have to have a platform-specific implementation, why not just stay with platform-native library loading?

[CrazyEddie]

Right okay. I'll make a decision about this shortly