Borland Project Files and Precompiled DLLs/LIBs for 1.7.1

[mdeininger]

Hey all,

just regging up to drop off a bit of goodness for y'all borland users:

http://kyuba.org/~mdeininger/irrlicht/

the .patch is a unified diff between the original 1.7.1 zip and what i had to do to get it working including the project file, and the .tar.bz2 is the complete distribution zip + borland .dll + .lib + .tds made with bcb2006 update 2.

background: we're using irrlicht for some projects at the place i work at; it's usually a bit of a pain to get working, because we're using the borland developer studio 2006. there do seem to have been some fixes merged into the irrlicht source in the latest releases, but usually i still get some compiler issues, and my boss said it's OK if i upload the changes i did to get it working for us, so there ye go.

note: as you can see in the compile config header, i disabled bzip2 and gui support, since both exhibited some weird compile issues and neither were used by us... and using the gui toolkit in borland has debatable merit. i didn't compile the test suite with this dll either, but i did try it on some of our projects and it seemed to work fine.

either way, enjoy and hope it helps someone else using irrlicht with borland.

P.S.: i'm available for testing things in borland, in case any of the devs would be interested. i'm probably not going to hang around on this forum too much, so if you'd like to get in touch, check irc.freenode.org, user "jyujin", i'm usually at least on channel #kyuba.

[CuteAlien]

Thanks for your patches. It seems borland doesn't like parameters of the the form function( what ? yes:no ) but needs more braces there. And seems to not do some automatic conversions, maybe it acts as if it had an explicit keyword for single parameter constructors as soon as more constructors exist (not sure)? I guess we can add most of those, except undefining features, but we should use io::path instead of core::string for the CFileList parameters. I hope that still works.

Just wondering - is there still some free Borland IDE (or whatever Borland calls itself these days) out there?

[mdeininger]

Hey there,

Yes, from what I can remember, the most prevalent problem was that with bcc expressions of this form:

Code: Select all

function/constructor-expression (cond ? a : b, c, d);

are seen as ambiguous and generally produce compiler errors. In theory, it could mean either of these:

Code: Select all

function/constructor-expression ((cond ? a : b), c, d);

Code: Select all

function/constructor-expression ((cond ? a : (b, c)), d);

Code: Select all

function/constructor-expression ((cond ? a : (b, c, d)));

It seems that other compilers will generally use the function argument separator interpretation of the comma instead of the comma-operator interpretation (which bcc will sometimes try to do), though I'm unsure as to which of the two is actually correct (I'm mostly doing straight C, and i find some operator precedence thingamajiggies in C++ to be somewhat weird). I'm also not sure whether bcc's refusal to automatically cast a or b in such expressions is legitimate or not; in theory it might be legitimate, since a and b are indeed supposed to be of the same type...

I did wonder about that free version of bcc too the other day. I remember getting one a few months back, they used to have one labeled as "Turbo C++" in analogy to their old compiler/IDE series. It was somewhat trimmed down and didn't support some of the higher end features, but it worked fine for me to port some of my private projects to bcc, since at home I tend to just use gcc or msvc++. I did hear that since the latest change in management, Turbo C++ has magically vanished from their website... well, maybe they'll put it back, who knows .

I think I'll check that later today, before my next seminar... love those WSI computer pools .

[hybrid]

Hmm, IIRC, the omma separator is the least strict binding one. But adding parantheses in these cases wouldn't hurt, but increase readability. So no problem with adding them.

[CuteAlien]

I just searched around a little for Borland compilers. Borland has sold them by now and they are now offered by Embarcadero: https://downloads.embarcadero.com/free/c_builder

[mdeininger]

hmm, but those are merely free trials and not the whole deal... they used to have the 2006 version stripped of most features available as a free download/non-trial version. and the 5.5 version on the same page is rather old and iirc only encompasses the command line tools. shame about that...

hybrid: i never trust the order in which comma operator and function argument separator end up binding. somehow those rules tend to be rather flakey among virtually all c-like languages, so personally i always use extra parentheses. and of course it does typically increase readability .

[CuteAlien]

OK, I got it mostly compiling on Borland. One exception is the CIrrDeviceConsole where I still have trouble with SetConsoleDisplayMode. Probably needs another include or maybe just not possible with Borland.

Just in case anyone else wants to try it out. I used the Version 5.5 from the embarcadero website. After installation you have to create a file called bcc32.cfg in the bin folder where you installed borland. For example I put it in "d:\Programme\Borland5.5\". It contains the default compiler includes like:

Code: Select all

-I"d:\Programme\Borland5.5\Include"
-I"d:\Programme\Microsoft DirectX SDK (August 2009)\Include"
-L"d:\Programme\Borland5.5\Lib"

(Yeah, I'm not sure about the -L thing here which looks wrong to me, but the official readme told me to add it in here. The readme also tells to create a file ilink32.cfg which contains the same line. Anyway - I only compiled, didn't try linking yet)

Then I used the following build command:
bcc32.exe -I../../include -Izlib -w-8027 -w-8057 -w-8012 -w-8030 -w-8004 *.cpp

(It's disabling a bunch of warnings)

@mdeininger: I did a few things slightly different. The namespace hack you used is not needed, instead the defines in irrMath.h should use the fully qualified names anyway. I put the _strcmpi in irrTypes.h. And I used io::path instead of core::string in a few places.

The changes are all in the 1.7 release branch in svn.

[mdeininger]

thanks cutealien, that sounds great!

I'll try to compile the svn version sometime during the week with the borland we're using (5.82), see if that still checks out (borland's got a thing for breaking stuff between releases...). i'm not even sure why i had to use that namespace hack, i think it was something weird as it were, but it's great to know it's not needed then.

btw, at least three of the signed/unsigned warnings borland spewed out seem legit. i mean the ones in scolor.h, seems like an f32 is being compared to an u32, which... might break between compilers. i posted about that on the bug forum already, though. im not entirely sure how the code oughta work there though, which is why i haven't tried to fix it myself.

[Greatwolf]

Hi,

I also recently downloaded irrlicht to play around with it again. I made quite a few modifications to get it to build under free bcc5.5.1. I was wondering if these changes can be incorporated into the svn so that future releases can build with borland compilers?

Here's a list of documented changes I had to make for Irrlicht to compile. Some of them are probably suggested by mdeininger already so there might be overlaps.

Code: Select all

//The source comment says DX8/9 headers don't come standard
//anymore on a typical environment. BCC certainly doesn't come with it
//so I've commented these 2 lines out
IrrCompileConfig.h
line 120-121
- #define _IRR_COMPILE_WITH_DIRECT3D_8_
- #define _IRR_COMPILE_WITH_DIRECT3D_9_
+ //#define _IRR_COMPILE_WITH_DIRECT3D_8_
+ //#define _IRR_COMPILE_WITH_DIRECT3D_9_-

// F_OK isn't defined anywhere I can see.
// Since MSVC preprocesses this line:
//    return (_access(filename.c_str(), 0) != -1);
// Borland should probably do the same
CFileSystem.cpp
line 748
- #if defined(_MSC_VER)
+ #if defined(_MSC_VER) || defined(__BORLANDC__)

// For some reason BCC doesn't like target == this.
// My guess is that it's trying to use this operator == prototype:
//   bool operator ==( IGUIElement* lhs, IGUIElement* rhs);
// but 'this' pointer is a const IGUIElement* type. So I fixed it by changing
// canTakeFocus()'s method to this signature instead:
//    bool CGUIModalScreen::canTakeFocus(const IGUIElement* target) const;
// This way, it'll force the BCC compiler to use this operator signature for equality comparison:
//    bool operator ==(const IGUIElement* lhs, const IGUIElement* rhs);
CGUIModalScreen.h
line 56
- virtual bool canTakeFocus(IGUIElement* target) const;
+ virtual bool canTakeFocus(const IGUIElement* target) const;

CGUIModalScreen.cpp
line 32
- bool CGUIModalScreen::canTakeFocus(IGUIElement* target) const
+ bool CGUIModalScreen::canTakeFocus(const IGUIElement* target) const

// Slightly change to this class method due to the const qualifier from above.
// Are there any potential issues with this? Does isMyChild() method change
// anything in the object or it's parameters?
IGUIElement.h
line 577
- bool isMyChild(IGUIElement* child) const
+ bool isMyChild(const IGUIElement* child) const

// BCC doesn't have the _ underscore prefixed for these string functions
// This is just a dirty hack, but perhaps a better approach is to put define alias
// in a header file and just include that header instead?
// Like for example,
//   #if defined(__BORLANDC__)
//   #define _strcmpi strcmpi
//   #endif
CIrrDeviceWin32.cpp
line 1104, 1106, 1108
- if (_strcmpi( "WINNT", szProductType) == 0 )
- if (_strcmpi( "LANMANNT", szProductType) == 0)
- if (_strcmpi( "SERVERNT", szProductType) == 0)
+ if (strcmpi( "WINNT", szProductType) == 0 )
+ if (strcmpi( "LANMANNT", szProductType) == 0)
+ if (strcmpi( "SERVERNT", szProductType) == 0)

// Just some wierd syntax error with the tenary operator and 
// implicit conversion issues like mdeininger pointed out earlier.
// Both issues are resolved by creating a temp object and enclosing
// the entire tenary expression with parenthesis.
CNPKReader.cpp
line 107
- : CFileList(file ? file->getFileName() : "", ignoreCase, ignorePaths), File(file)
+ : CFileList((file ? file->getFileName() : path("")), ignoreCase, ignorePaths), File(file)
line 225
- addItem(isDir?dirName:dirName+entry.Name, entry.Length, isDir, Offsets.size());
+ addItem( (isDir?dirName:dirName+entry.Name), entry.Length, isDir, Offsets.size());

CNullDriver.cpp
line 729
- sourceRect, clipRect, colors?colors[0]:0xffffffff,
+ sourceRect, clipRect, colors?colors[0]:SColor(0xffffffff),

CPakReader.cpp
line 103
- : CFileList(file ? file->getFileName() : "", ignoreCase, ignorePaths), File(file)
+ : CFileList((file ? file->getFileName() : path("")), ignoreCase, ignorePaths), File(file)

CTarReader.cpp
line 128
- : CFileList(file ? file->getFileName() : "", ignoreCase, ignorePaths), File(file)
+ : CFileList((file ? file->getFileName() : path("")), ignoreCase, ignorePaths), File(file)

CZipReader.cpp
line 142
-  : CFileList(file ? file->getFileName() : "", ignoreCase, ignorePaths), File(file), IsGZip(isGZip)
+  : CFileList((file ? file->getFileName() : path("")), ignoreCase, ignorePaths), File(file), IsGZip(isGZip)

// BCC needs tchar.h included with crtdgb.h otherwise undefined errors come up
Irrlicht.cpp
line 12
- #include <crtdbg.h>
+ #if defined(__BORLANDC__)
+     #include <tchar.h>
+ #endif
+ #include <crtdbg.h>

// This one took me some time to figure out. The problem turns out
// BCC's preprocessor isn't fully expanding all those macro levels
// when you concatenate strings (using ##) and then pass that as argument
// into another macro expansion. So you end up with preprocessed units that look 
// like this:
//     const aes_32t t_fn[4][256] = { { u0(0x00), u0(0x08)
//  when it should really look like this:
//     const aes_32t t_fn[4][256] = { { (((aes_32t)((((0x63<<1)
// To correct this issue, I defined a string concating macro and I modified the defines
// to use that macro whenever it needed to concatenate a string.
aesopt.h
line 850-851
- #define d_1(t,n,b,v) const t n[256]    =   { b(v##0) }
- #define d_4(t,n,b,v) const t n[4][256] = { { b(v##0) }, { b(v##1) }, { b(v##2) }, { b(v##3) } }
+ #if defined(__BORLANDC__)
+    #define concat(s1, s2) s1##s2
+    #define d_1(t,n,b,v) const t n[256]    =   { b(concat(v,0)) }
+    #define d_4(t,n,b,v) const t n[4][256] = { { b(concat(v,0)) }, { b(concat(v,1)) }, { b(concat(v,2)) }, { b(concat(v,3)) } }
+ #else
+    #define d_1(t,n,b,v) const t n[256]    =   { b(v##0) }
+    #define d_4(t,n,b,v) const t n[4][256] = { { b(v##0) }, { b(v##1) }, { b(v##2) }, { b(v##3) } }
+ #endif

// BCC 5.5.1 doesn't support the long long datatype. 
// __int64 is defined though so we can use that instead for 
// 64bit variables. BCC 5.82 (BSD2006) does seem to support long long though.
// Someone with that compiler might need to confirm this for me.
sha2.h
line 60-61
- #ifdef _MSC_VER
- #if _MSC_VER < 1300
+ #if defined(_MSC_VER) || defined(__BORLANDC__)
+ #if (_MSC_VER < 1300) || (__BORLANDC__ < 0x582)

One last note, I did run into the same problem with SetConsoleDisplayMode not being defined. What I did to correct this issue was to add that function signature into my wincon.h file and then I created an import library from the kernel32.dll which has this function. Also check the post I made here for some other ideas suggested for solving this issue.
Let me know of any comments and feedbacks.

Thanks

[CuteAlien]

@Greatwolf, thx for trying it. Although it would be good if you could test it with svn trunk or svn branch 1.7 - both contain already the changes I mentioned above.

Unfortunately I won't find time next few weeks for Irrlicht (not before October probably), but maybe someone else in the team wants to check out Borland?

[hybrid]

Yeah, I could find some time. Please copy this post to the bug forum (don't mind cross posting here ) as I could otherwise lose track of it. Or maybe submit a bug ticket at the SF trackers for Irrlicht.

[Greatwolf]

Alright, I had some time and I got a chance to download the current SVN trunk. Here are the list of changes I made to get it to build under bcc:

Code: Select all

// bcc has macro expansion problems. See my list from earlier post
aesopt.h
line 850-851
- #define d_1(t,n,b,v) const t n[256]    =   { b(v##0) }
- #define d_4(t,n,b,v) const t n[4][256] = { { b(v##0) }, { b(v##1) }, { b(v##2) }, { b(v##3) } }
+ #if defined(__BORLANDC__)
+    #define concat(s1, s2) s1##s2
+    #define d_1(t,n,b,v) const t n[256]    =   { b(concat(v,0)) }
+    #define d_4(t,n,b,v) const t n[4][256] = { { b(concat(v,0)) }, { b(concat(v,1)) }, { b(concat(v,2)) }, { b(concat(v,3)) } }
+ #else
+    #define d_1(t,n,b,v) const t n[256]    =   { b(v##0) }
+    #define d_4(t,n,b,v) const t n[4][256] = { { b(v##0) }, { b(v##1) }, { b(v##2) }, { b(v##3) } }
+ #endif

// See comment from my earlier post
sha2.h
line 60-61
- #ifdef _MSC_VER
- #if _MSC_VER < 1300
+ #if defined(_MSC_VER) || defined(__BORLANDC__)
+ #if (_MSC_VER < 1300) || (__BORLANDC__ < 0x582)

// bcc needs an extra set of parenthesis for the default template temporary object.
// It seems to have trouble calling the correct ctor otherwise.
ICursorControl.h
line 71
- SCursorSprite( gui::IGUISpriteBank * spriteBank, s32 spriteId, const core::position2d<s32> &hotspot=core::position2d<s32>(0,0) )
+ SCursorSprite( gui::IGUISpriteBank * spriteBank, s32 spriteId, const core::position2d<s32> &hotspot=(core::position2d<s32>(0,0)) )

// 'ECOLOR_FORMAT format' is prototyped with a const but
// COpenGLFBOTexture ctor is trying to assign to it. What is going
// on here? Needless to say I got a compile error complaining
// it's trying to modify a const object.
COpenGLTexture.h
line 154
- COpenGLDriver* driver = 0, const ECOLOR_FORMAT format = ECF_UNKNOWN);
+ COpenGLDriver* driver = 0, ECOLOR_FORMAT format = ECF_UNKNOWN);

/* For CXMLReaderImpl.h on lines 597 & 604, I get an Ambiguous error 
 * between xmlChar<unsigned int>::xmlChar(char) and 
 * xmlChar<unsigned int>::xmlChar(wchar_t). For some odd reason I can't
 * get bcc to use xmlChar<T>(unsigned int) ctor. Commenting out explicit was 
 * the only way I could get it to work. Perhaps someone could offer a better solution?
 */
irrXML.h
line 377
- explicit xmlChar<T>(unsigned int in) : c(static_cast<T>(in)) {}
+ /*explicit*/ xmlChar<T>(unsigned int in) : c(static_cast<T>(in)) {}

// The method itself is suppose to return a pointer, not a boolean.
// I changed it to 0 to fix the compile error. NULL could work here too.
CAnimatedMeshHalfLife.cpp
line 1038
- return false;
+ return 0;

Additionally, I created a new header file called IrrBorlandConfig.h for dealing with some of the different compiler specific stuff:

IrrBorlandConfig.h

Code: Select all

#ifndef __BORLANDC__
    #error IrrBorlandConfig.h is being included in a non-Borland Toolchain build!
#endif

#ifndef __IRR_BORLAND_CONFIG_H_INCLUDED__
#define __IRR_BORLAND_CONFIG_H_INCLUDED__
#include <tchar.h>

// Comment these two lines if you have DX8/9 SDK
//  setup for your Borland environment
#undef _IRR_COMPILE_WITH_DIRECT3D_8_
#undef _IRR_COMPILE_WITH_DIRECT3D_9_

// Borland 5.5.1 does not have _strcmpi defined
#if __BORLANDC__ == 0x551
//    #define _strcmpi strcmpi
    #undef _tfinddata_t
    #undef _tfindfirst
    #undef _tfindnext

    #define _tfinddata_t __tfinddata_t
    #define _tfindfirst  __tfindfirst
    #define _tfindnext   __tfindnext
#endif

#endif // __IRR_BORLAND_CONFIG_H_INCLUDED__

And I add it for inclusion at the bottom of IrrCompileConfig.h

Code: Select all

IrrCompileConfig.h
line 517
+ #if defined(__BORLANDC__)
+    #include "IrrBorlandConfig.h"
+ #endif

I have a CodeBlocks project-file and workspace configured to use bcc 5.5.1 with the same build targets as vcproj:

• Debug Win32
  Release Win32
  Release - Fast FPU Win32
  Static lib - Debug Win32
  Static lib - Release Win32
  Static lib - Release - Fast FPU Win32
  SDL-Debug Win32

Should I upload and submit my project files and changes here?
Let me know what your thoughts are.

Thanks

[hybrid]

You can submit at our patch tracker, which is easier for file uploads, and those tickets won't be lost due to too many posts in a forum.

[Greatwolf]

Thanks will look into that