[rant-ish?] [pre-solved] problems building VS2013 community

[Cube_]

The goal of what I'm doing right now is to just get a solid testbed up for some hacks I want to make for irrlicht, this should be simple enough in theory - the project is untouched thus far [aside from having removed every reference to the direct3d renderers since I don't use them] - simple stuff really.

So first I tried compiling the Irrlicht11.0 solution - this didn't work, it kept wanting me to install the Windows 7.1SDK which I don't have and don't want [or need, I'm not building the d3d renderers]
Since it didn't let me upgrade the solution within the IDE I instead did it manually, it's now up to date and the platform toolset is defined as v120 (the VS2013 C++ compiler), all fine and dandy - compilation works reasonably well, until we hit irrXML.cpp [every other file built, this is verified by the fact that it didn't abort on

Configuration(s) tested: Debug (DLL) - Win32, Debug (DLL) - x64

Errors:

Code: Select all

 
1>Irrlicht.cpp(52): error C2491: 'irr::createDevice' : definition of dllimport function not allowed
1>Irrlicht.cpp(66): error C2491: 'irr::createDeviceEx' : definition of dllimport function not allowed
 
1>irrXML.cpp(85): error C2491: 'irr::io::createIrrXMLReader' : definition of dllimport function not allowed
1>irrXML.cpp(92): error C2491: 'irr::io::createIrrXMLReader' : definition of dllimport function not allowed
1>irrXML.cpp(100): error C2491: 'irr::io::createIrrXMLReader' : definition of dllimport function not allowed
1>irrXML.cpp(117): error C2491: 'irr::io::createIrrXMLReaderUTF16' : definition of dllimport function not allowed
1>irrXML.cpp(124): error C2491: 'irr::io::createIrrXMLReaderUTF16' : definition of dllimport function not allowed
1>irrXML.cpp(132): error C2491: 'irr::io::createIrrXMLReaderUTF16' : definition of dllimport function not allowed
1>irrXML.cpp(149): error C2491: 'irr::io::createIrrXMLReaderUTF32' : definition of dllimport function not allowed
1>irrXML.cpp(156): error C2491: 'irr::io::createIrrXMLReaderUTF32' : definition of dllimport function not allowed
1>irrXML.cpp(164): error C2491: 'irr::io::createIrrXMLReaderUTF32' : definition of dllimport function not allowed

Okay, so that points to this.

Code: Select all

IRRLICHT_API IrrXMLReader* IRRCALLCONV createIrrXMLReader(const char* filename)
{
    return createIrrXMLReader(new CFileReadCallBack(filename), true); 
}

And after poking around a bit I find that IRRLICHT_API is defined here:

Code: Select all

#ifndef _IRR_STATIC_LIB_
#ifdef IRRLICHT_EXPORTS
#define IRRLICHT_API __declspec(dllexport)
#else
#define IRRLICHT_API __declspec(dllimport)
#endif // IRRLICHT_EXPORT
#else
#define IRRLICHT_API
#endif // _IRR_STATIC_LIB_

And based on syntax highlighting it decided that the dllimport method is the logical option.
Except to my understanding it should be the dllexport option - since using dllimport on a definition is illegal.

I wonder why.
In any case, I suppose I could hack it by defining IRRLICHT_EXPORTS but that sounds really dodgy, I'm mostly posting to see if anyone has had this happen to them and why - it's rather perplexing [most likely due to my own lack of programming skills, but that's why I'm [planning on] messing around with irrlicht's internals in the first place - haven't done much aside from define NO_IRR_COMPILE_WITH_DIRECT3D_8_ and NO_IRR_COMPILE_WITH_DIRECT3D_9_ thus far, and nuking the d3d9 renderer files from the project since they're not used anyway (which doesn't make a difference because it happens even with them still there - the problem stems from irrXML)]

presumably the exact same would happen even without the NO_IRR_COMPILE_WITH_DIRECT3D_x_ defines.
So... maybe I do need the Windows 7.1SDK after all? Although it doesn't seem to be related to that in any way, it seems to be due to a missing IRRLICHT_EXPORTS definition (because after batch searching every file in the solution there's no #define IRRLICHT_EXPORTS anywhere to be found).

After hacking it in it it compiles just fine. (well mostly, there's a linking error due to me removing the software driver without instructing the compiler to not compile it in - but that's my fault, after adding NO_IRR_COMPILE_WITH_SOFTWARE_ it compiles just fine)

I suppose this should actually be a bug report?
Given that it fails to compile under MSVC2013 Community unless one manually hacks in a #define IRRLICHT_EXPORTS

Specifically because the IrrCompileConfig header contains a bug that tells the compiler to generate imports where syntactically illegal.
Yes, this is a fresh download of 1.8.3 right from http://irrlicht.sourceforge.net/?page_id=10

After downloading it again there are still no definitions of IRRLICHT_EXPORTS in IrrCompileConfig.h and this version causes the same error on my end [when built with VC120 - after the Windows SDK7.1 defines have been changed, naturally - it won't compile at all with them intact]


Well, it's in off-topic for a reason. (I have no idea where to put it!) Besides, I am more curious as to the reasons of it not working without hacking in a solution myself rather

Well, I suppose my root point of all this is: I don't enjoy building under windows, something always gets in my way.
But for now I found a hack to solve it with.

Question: how would irrlicht ever compile without IRRLICHT_EXPORTS being defined?

you can't make mark a function as __declspec(dllimport) if it has a definition so without it defined every function in irrXML.cpp should rightly err out, no? (there's a good reason why this is in off-topic, aside from not knowing where it goes, and that is that I'm not familiar enough with Irrlicht to call this a bug. Merely an unusual experience!)

P.S Sorry for this being so ranty, I couldn't figure out a good way to edit it after proofreading.

[Cube_]

Oh yes, I should point out that this is a bad solution in any case since the IRRLICHT_API #ifdef cluster is there to allow using the same include for both the client app and the library.
However my goal right now was just to compile it - I have clean headers in my include path for projects that use them.

The main caveat here is that you'll [probably] get strange errors if you try to include a modified IrrCompileConfig that contains this hack [since it'll try to mark the methods in the software as exports which I'm fairly certain is illegal!]

[CuteAlien]

Long post *sigh*. First - requiring Windows 7.1 SDK was one of our ideas working around the mess Microsoft delivers. It is basically impossible to mix dll's from different VS versions - unless you install old VS versions and set those as targets. Because newer VS versions never include support for older VS compilers.
The Windows 7.1 SDK was the only one I found that could be installed without users having to install the corresponding VS version (it's basically something like the version of VS 2008 or VS 2010 or so). The alternative is that we no longer distribute any dll - which we might do in the future. We think about it when it comes to release Irrlicht 1.9. (another alternative would be create X dll's for each VS version like MS does, but given our non-existent resources I don't think we will do that)

If you want other versions then change the platform toolset settings to whatever version you want (for example the current one for whichever VS compiler you have installed). You just have to ensure it is set to the same version in Irrlicht, your application and all dll's you are using.

Your errors looks like you try compile Irrlicht statically without setting _IRR_STATIC_LIB_.
It's not an Irrlicht specific hack, but something a lot of libraries are doing. When working with c/c++ libs you generally need to set a define when compiling them statically (sometimes they have setup-tools which create headers for you doing that - but that creates it own share of troubles).
So follow the docs:
// To build Irrlicht as a static library, you must define _IRR_STATIC_LIB_ in both the
// Irrlicht build, *and* in the user application, before #including <irrlicht.h>

[Cube_]

Long post *sigh*. First - requiring Windows 7.1 SDK was one of our ideas working around the mess Microsoft delivers. It is basically impossible to mix dll's from different VS versions - unless you install old VS versions and set those as targets. Because newer VS versions never include support for older VS compilers.
The Windows 7.1 SDK was the only one I found that could be installed without users having to install the corresponding VS version (it's basically something like the version of VS 2008 or VS 2010 or so). The alternative is that we no longer distribute any dll - which we might do in the future. We think about it when it comes to release Irrlicht 1.9. (another alternative would be create X dll's for each VS version like MS does, but given our non-existent resources I don't think we will do that)

If you want other versions then change the platform toolset settings to whatever version you want (for example the current one for whichever VS compiler you have installed). You just have to ensure it is set to the same version in Irrlicht, your application and all dll's you are using.

Oh, I see - so that explains the reason for the SDK.
I already made the change myself, it was a pretty easy operation, find and replace "Windows 7.1SDK" > "v120"

Your errors looks like you try compile Irrlicht statically without setting _IRR_STATIC_LIB_.
It's not an Irrlicht specific hack, but something a lot of libraries are doing. When working with c/c++ libs you generally need to set a define when compiling them statically (sometimes they have setup-tools which create headers for you doing that - but that creates it own share of troubles).
So follow the docs:
// To build Irrlicht as a static library, you must define _IRR_STATIC_LIB_ in both the
// Irrlicht build, *and* in the user application, before #including <irrlicht.h>

Ah, but The fun thing is - I'm not building a static lib [and indeed, the binary it output was a dll - as one would expect], unless visual studio tried to build both at the same time (which I doubt, because there's no static lib built)
However, that doesn't seem likely since

Debug win32 != Static lib - Debug win32

I already know how to build statically, I just don't do it - there's no good reason to imo.
Where is #define IRRLICHT_EXPORTS supposed to be anyway?
I couldn't find it in any of the files in the solution [visual studio is not necessarily telling the truth though]

Code: Select all

Find all "IRRLICHT_EXPORTS", Subfolders, Find Results 1, "Entire Solution ( Including External Items )", ""
  C:\Users\Thunder\Documents\irrlicht-1.8.3\include\IrrCompileConfig.h(683):#ifdef IRRLICHT_EXPORTS
  C:\Users\Thunder\Documents\irrlicht-1.8.3\include\IrrCompileConfig.h(702):#if (__GNUC__ >= 4) && !defined(_IRR_STATIC_LIB_) && defined(IRRLICHT_EXPORTS)
  C:\Users\Thunder\Documents\irrlicht-1.8.3\include\irrTypes.h(212):#if defined(_DEBUG) && defined(IRRLICHT_EXPORTS) && defined(_MSC_VER) && \
  Matching lines: 3    Matching files: 2    Total files searched: 985

In no file does it actually define IRRLICHT_EXPORTS as far as I can tell.
And this confuses me, because I have built in mingw and g++ - it's just MSVC 2013 that behaves weirdly. [or maybe it's behaving more correctly?]

[CuteAlien]

IRRLICHT_EXPORTS must be in the project file. It can't be in the header as it needs different values depending on wether you compile Irrlicht or a project using Irrilcht (Irrlicht is the library so it has to export the functions while the applications using it have to import them).

So in this case the problem isn't compiling as static I guess but that IRRLICHT_EXPORTS is missing in your compiler defines sections in the Irrlicht project file (it doesn't have to be in your application).

[Cube_]

so IRRLICHT_EXPORTS should be defined in the solution as a global variable or something then?
I wonder why it isn't, I didn't touch anything but the platform toolkit...

Well, I'll look around further.

IRRLICHT_EXPORTS must be in the project file. It can't be in the header as it needs different values depending on wether you compile Irrlicht or a project using Irrilcht (Irrlicht is the library so it has to export the functions while the applications using it have to import them).

Ah yes, I'm aware - my hack is to just have duplicate headers, it's crude, non-portable, and really really ugly.
But it got the job done [temporary test to see if I could get visual studio 2013 to compile it at all].

Now I can start messing with irrlicht a bit more, which calls for solving it properly so now I must read up on how to define it globally in the project [or rather, poke around the menus and read up if I can't find it myself]