I am taking the appraoch of using a system like in OgreDynLib.h as suggested by _mental_, though the Mac will still use some implementation specifics via the macPlugins.cpp/.h files.
What I have not yet resolved is the module naming differences that we currently have between Win32 and Linux. For Linux the libs are created with the libCEGUI prefix, and under Win32 they're not. What I thought about doing was adding the CEGUI prefix to the Win32 (and Mac) module names, and putting in a conditional for linux that automatically adds the leading 'lib' if it is not present. I'd be glad to hear (especially from _mental_ ) if this a good idea or not, or if there's something I've maybe missed.
CE.
Same DLL-String for all OS in the scheme file
Moderators: CEGUI MVP, CEGUI Team
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Same DLL-String for all OS in the scheme file
I will add the _d suffix thing as a compile time options for Win32 users. The way it will work is if you specify the file without the .dll extenstion and it's the debug build, the _d will be added. In release builds, or for names that have the .dll extension, nothing will be touched.
I'm reluctant to start adding reams of code saying try this name, if that fails try some other name, and so on. The creator of the data file should really know the name of their files!
CE.
I'm reluctant to start adding reams of code saying try this name, if that fails try some other name, and so on. The creator of the data file should really know the name of their files!
CE.
Same DLL-String for all OS in the scheme file
I am taking the appraoch of using a system like in OgreDynLib.h as suggested by _mental_, though the Mac will still use some implementation specifics via the macPlugins.cpp/.h files.
What I have not yet resolved is the module naming differences that we currently have between Win32 and Linux. For Linux the libs are created with the libCEGUI prefix, and under Win32 they're not. What I thought about doing was adding the CEGUI prefix to the Win32 (and Mac) module names, and putting in a conditional for linux that automatically adds the leading 'lib' if it is not present. I'd be glad to hear (especially from _mental_ ) if this a good idea or not, or if there's something I've maybe missed.
It looks like I've missed the thread.. sorry had RL stuff to deal with. Anyway I'd completely forgotten that I'd suggested using libltdl before (the old brain isn't working as well as it used to ).
Technically all of the plugins shouldn't be prefixed with lib anyway. This was done because of the way dlopen & the ld.so.cache works and I always meant to come back and fix this. If you prefix the plugin/library and place it within a path in ld.so.conf (or a standard path such as /usr/lib), when you run ldconfig this will be cached. The benefit to that is that you can use dlopen without needing a full path. Plugins shouldn't really be cached in /etc/ld.so.cache so I'm all for this. I'd suggest that we create a subdirectory called CEGUIPlugins in the lib dir where the main CEGUI libraries are installed (on my system it would be /usr/local/lib/CEGUIPlugins). All of the plugins would reside in there. The only other thing we need to do is have a way of specifying the library path. This could be done by adding the path to the library name in the XML file, or by adding a new XML node which contains the path to all of the plugins. I like the latter idea personally.
Sorry if this seems disjointed or contractictory but I'm doing this quickly from work using lynx. I'll come back later and correct any mistakes
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Same DLL-String for all OS in the scheme file
Thanks for the input
I actually implemented what I said earlier with regards to the lib prefix and stuck it in beta1-devel branch. You can take a look at that if you like, obviously this can still be changed though. I am also going to be modifying the Win32 names to be CEGUITaharezLook and CEGUIWindowsLook, which brings them in line with the Linux names.
The new scheme file for TaharezLook widgets starts like this:
Ideally, it will be possible to use this same xml file for specifying the module to be loaded on all platforms, and have the system find the module in some appropriate manner.
I'm not sure if having a path specified in there is a solution, unless it were to be relative to some point common for all platforms.
Apparently, there's still some work that needs to be done here
CE.
I actually implemented what I said earlier with regards to the lib prefix and stuck it in beta1-devel branch. You can take a look at that if you like, obviously this can still be changed though. I am also going to be modifying the Win32 names to be CEGUITaharezLook and CEGUIWindowsLook, which brings them in line with the Linux names.
The new scheme file for TaharezLook widgets starts like this:
Code: Select all
<?xml version="1.0" ?>
<GUIScheme Name="TaharezLookWidgets">
<WindowSet Filename="CEGUITaharezLook">
.
.
.
Ideally, it will be possible to use this same xml file for specifying the module to be loaded on all platforms, and have the system find the module in some appropriate manner.
I'm not sure if having a path specified in there is a solution, unless it were to be relative to some point common for all platforms.
Apparently, there's still some work that needs to be done here
CE.
Same DLL-String for all OS in the scheme file
I just saw CEGUI_LOAD_MODULE_APPEND_SUFFIX_FOR_DEBUG.
Thank you!
Thank you!
Return to “Bug Reports, Suggestions, Feature Requests”
Who is online
Users browsing this forum: No registered users and 8 guests