static lib and NeL port

[jays]

Good afternoon programmers!

I'm in the process of writing the 0.7 version renderer/etc for the NeL engine.
I had a few questions, perhaps some of you have a few answers?

Is there a good reference on what's needed for a static library build?
I have the NeL code written and compiled but when I tried to display a "Hello World" window I found I was missing functions.
There are globals, and perhaps factory classes, that I need to make aware of the new NeL classes.

I also noted some problems with the organization of the include files.

If you want a static library build you need to change many of the .cpp files, They do not include config.h so they will all erroneously generate dll export declarations. The only alternative is to define constants on the compiler command line.

There are a number of constants in config.h. This sets up the library export declarations etc.
If your own project has a config.h then trying to use the CEGUI include files becomes a problem.
You only get one of the config files included and end up with lots of missing declarations.

Any suggestions how to combat these issues?

Thanks!

[CrazyEddie]

Firstly I'll say that your post makes many claims of issues, but contains no specific information, which makes it extremely hard do have any idea about why you're seeing the issues you are. You have not specified the system you're trying to do this on - which is important. Though from the mention of DLL and export controls, I assume Windows.

The current static build for windows works fine using the supported build systems on that platform; there is certainly no need to modify CEGUI source files, config.h is included only where necessary, and generally dll import/export controls are in an appropriate header file and not in .cpp source files.

The static build is controlled via CEGUI_STATIC being defined at the project level, it is not defined in config.h and neither is any mechanism or macro definition for controlling DLL import/export.

As for the config.h file, none of the CEGUI headers except one of the Irrlicht files includes config.h, and presumably you're not using this file.

CE

[jays]

I get the impression my post was taken as a criticism. That wasn't my intention. I wanted to contribute something back. If you found it offensive you have my apologies.

My environment:
I'm using the Netbeans IDE (with mingw gcc for windows) in hopes of having a single development environment for both Windows and Linux.

Here's the issue in detail:

In CEGUIBase.h is the following compiler directive:

Code: Select all

#if (defined( __WIN32__ ) || defined( _WIN32 )) && !defined(CEGUI_STATIC)
#   ifdef CEGUIBASE_EXPORTS
#       define CEGUIEXPORT __declspec(dllexport)
#   else
#       define CEGUIEXPORT __declspec(dllimport)
#   endif
#       define CEGUIPRIVATE
#else
#       define CEGUIEXPORT
#       define CEGUIPRIVATE
#endif


If you're compiling a static library you must define CEGUI_STATIC. Since, as you said, config.h is not included by most of the .cpp files then it must be defined as a compiler command line option in the project. I then compile a static library and then try to use CEGUI in a separate project (for windows). The CEGUI_STATIC options must also be placed in my new project's options or all declarations will default to dllexport. You get massive numbers of less than obvious errors from the linker.

One of the other problems is the name of the configuration file. If I also have a config.h (I have a class to load my own project's configuration options) then
#include "config.h" becomes ambiguous when I add the cegui include directories to my project.

In summary:
The concept of namespaces is used in the code to prevent collisions, but it's not used in the naming conventions of one of the include files (i.e. config.h).

It's just my preference but it would also be very helpful if all of the configuration options for the code were actually in the include files instead of some of them being in the project settings. It makes one less thing I can do wrong when I'm writing a new project to use CEGUI (forgetting to set CEGUI_STATIC).

[CrazyEddie]

I get the impression my post was taken as a criticism.

Not at all. I was frustrated with the lack of specifics in your initial posting which prevented me from seeing the causes of the issues you were / are having and therefore being unable to offer quick and concise help or comment on those issues. I am always willing to hear feedback and suggestions for improvement. When taking about the build set up, usually - but certainly not always - you will find that there are specific reasons why things have been done a certain way.

CEGUI_STATIC is defined at the project level because on Windows we support building and using multiple configurations (meaning, static and non-static). If CEGUI_STATIC were to exist in some configuration file (such as config.h) this would preclude us from achieving this goal so easily - the library would have to be build one way or the other, which is not particularly flexible. Adding CEGUI_STATIC to your project to 'select' the static configuration is, at least in my own opinion, no great hassle

The situation is similar when building the system as DLLs - you have to define the appropriate macro to control import/export, and again, this can't be put in a config file (or even be a single macro name used for all DLLs) because the state of the macro (defined, or not) needs to vary according to whether you're building a specific CEGUI DLL or using that specific CEGUI DLL (which applies to CEGUI itself, because it comprises multiple DLLs, some of which link to others).

I think I misunderstood the issue with config.h from your initial post. This file should not really be in with the public headers, you should be able to delete this file with no ill effects, for future releases I will ensure that this file is not included in the package. For info, this file is not installed on linux systems, and does not exist at all for the Mac build

I've mentioned it previously to scriptkid that it would be good to have a header that contains configuration details used for the build (but not called config.h). We actually have the CEGUIConfig.h file that used to be for this purpose way back in the distant past (and still is used for this purpose on the Mac). I have plans to revive the usage of that file for all platforms, although it must be stated that this would not contain things like CEGUI_STATIC for the reasons already given above.

In order to avoid misinterpretation of certain parts of the above, I would like to add that this reply is not intended to be 'defensive', but rather to clarify that their are - at least what we consider to be - good reasons why things are the way they are, with the notable exception of the config.h file being in the public headers - that one may certainly be considered a mistake

CE.

[jays]

I'll make sure to post a link to the NeL version when I get it working. Thanks for sharing all your hard work with us.

It'll be interesting to see what I can do with the new version of your code. With all the flashy new UI stuff that's appearing lately I feel like I have to add some flash to the user interface just to not appear 'dated'. Most of it isn't anything other than eye candy but that doesn't change people's perceptions. I do like the autohide feature though. As an old guy,
with old eyes, I can sure use the extra screen space sometimes.