mingw port

[GoogleCodeExporter]

It would be nice to be able to compile BWAPI using the free and easy to set 
up MingW compiler (based on GCC), which also runs under Linux/WINE.
I have already contributed a preliminary patch but the work is not done 
yet.

To do so, we must avoid using any proprietary Visual C++ compiler/library 
extensions such as:

* for each statement, instead use <Util/Foreach.h>:
  foreach(Type& elem, collection) { ... }
  If the type name contains a comma, use a local typedef:
  typedef std::pair<int, float> pair;
  foreach(pair& p, collection) { ...}

* all the *_s functions, such as memcpy_s, fprintf_s, .... If possible, use 
the regular functions or add/use a port from <Util/Gnu.h>

* (not strictly necessary) Use / in paths, #include <Dir/File.h>, not 
#include <Dir\File.h>

Also, the Intel-syntax inline assembly must be ported to AT&T syntax which 
GCC uses.

The latest MingW can be obtained from http://tdragon.net/recentgcc/

Original issue reported on code.google.com by slowb...@gmail.com on 3 Dec 2009 at 9:58

[GoogleCodeExporter]

patch against r1750

Original comment by slowb...@gmail.com on 3 Dec 2009 at 11:13

Attachments:

• mingw2.patch

[GoogleCodeExporter]

I strongly oppose. BWAPI is bound to Starcraft and is not required to compile 
by 
user by any means. BAgent we could make portable though...

Original comment by goo...@teabix.com on 3 Dec 2009 at 11:16

[GoogleCodeExporter]

After some experimenting and porting all the assembly, __declspec(naked) does 
not 
work properly in GCC, which makes the assembly code for those functions invalid 
since 
GCC either generates stack frame setup or register saves (with 
omit-frame-pointer). 
(if you are interested in details, mail me)

All this makes the likelihood of a MingW inline assembly port quite low, 
meaning the 
__MINGW32__ #ifdef's could probably be removed from DLLMain.cpp and Engine.cpp.

Guess this means that focus should be on BWAgent client-only porting.

For the future: getting rid of the inline assembly (by using assembly in a 
separate 
file or developing a generic hooking system a la Microsoft Detours) will make a 
full 
GCC port possible.

The porting layer used for the experiment is attached, for the curious.

Original comment by slowb...@gmail.com on 4 Dec 2009 at 2:43

Attachments:

• Asm.h

[GoogleCodeExporter]

I would like this thread to include all the arguments why we should port it at 
all. "It would be nice" is how you began, and then suggested to rewrite loads 
of 
code into a syntax that deprives it of VC++s benefits. If we seriously decide 
to 
port the project, "how" is not an issue.

Please note: we can compile BWAgent.cpp so it can be used by any compiler, you 
do 
not have to recompile it to be able to use it's interface in your gcc or MinGW 
or 
whatever.

Please numerize each argument.

Original comment by goo...@teabix.com on 4 Dec 2009 at 3:07

[GoogleCodeExporter]

With my last few commits bwapi now compiles (but does not yet link) in gcc. But 
yeah
it sounds like GCC's version of __declspec(naked) - __attribute__((naked)) - 
does not
work properly, so unless someone is able to fix/update gcc, theres little point
pursuing this matter further since those functions must be naked for BWAPI to 
work.

I agree with Teabix and Slowbyte - we should just focus on making sure its 
possible
to compile BWAgent in both gcc and visual studio.

Original comment by lowerlo...@gmail.com on 4 Dec 2009 at 4:03

[GoogleCodeExporter]

(for the current code, which already compiles with GCC), not much benefits were 
deprived, just some minor syntactical changes and fixes for bugs which VC++ 
does not 
recognize.

In any case, it is a question of taste, so not much to argue about it - a 
couple of 
people wanted a MingW port because they find it better than VC++, and therefore 
it 
was coded. The changes proposed do little harm to people who use VC (it's not 
like 
anybody was asking VC developers to port their code to MingW itself or to 
ensure that 
the code always compiles with GCC).

Any further discussion along these lines would probably be pointless and end as 
yet 
another flamewar...

Original comment by slowb...@gmail.com on 4 Dec 2009 at 1:08

[GoogleCodeExporter]

Original comment by lowerlo...@gmail.com on 7 Dec 2009 at 6:09

• Changed state: Questionable
• Added labels: Type-Enhancement, Priority-Low

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

in case you just tuned in:
BWAPI1 is the native C interface provided by BWAPIv3.0 in future
BWAPI2 is the object oriented C++ interface provided by BWAPIv3.0 in future, 
which 
tends to be compatible with BWAPIv2.5.

EDIT: I realized that part of my previous post was off-topic and independent 
from 
this one. I removed it.

The "virtual interface" turns out to be a too complicated (or too powerfull?) 
approach for just C++ portability. See the forked COM issue for more details. 
Instead I had an idea based on this fact:
BWAPI1 interface can be seen as "the original", whereas BWAPI2 is just a C++ 
wrapper.

Put the BWAPI2 "wrapper" interface in a separate module e.g. BWCpp.dll. We 
won't 
practically have to adapt any code, because BWAPI2 is not dependent on the 
BWAgent 
internals, only on the BWAPI1 interface, which well qualifies BWAPI2 as a 
separate 
module, all you have to do is to put the files in a separate project.

The performance penalty is negligible. (one assembler jmp instruction more per 
BWAPI2 function call)
The usage stays the same (load .lib, include headers). Your AIModule.exe loads 
BWCpp.dll. BWCpp.dll itself loads BWAgent.dll.

The advantages are:
- I noticed many things would have to be changed in BWAPI2 to ensure 
portability 
with the "virtual interface" approach. See the forked COM issue for details. 
With 
this, nothing has to be changed.
- The BWCpp.dll can be compiled in any compiler you want. We can provide 
BWCpp2005.dll, BWCpp2008.dll, and the rest (like gcc) can compile their .dlls 
themselves.
- Maintaining this portability is easy because we won't have to keep the whole 
BWAgent.dll portable, only the relatively simple BWCpp.dll "wrapper" part.
- It is possible to make static .libs instead of .dlls. There is really no 
usage 
difference. There's only one aesthetic difference: the .dll is a 
separate file, whereas the .lib is compiled into the AIModule.exe of the user.

If noone sees a problem with this idea, I'll implement this after the BWAPIv3.0 
release.

Original comment by goo...@teabix.com on 26 Dec 2009 at 1:24

[GoogleCodeExporter]

the BWAPI1 interface is not native anymore. It dragged the project down, with 
imaginary gains (as far as I could predict over the weeks, the usage of the 
feature 
would be minimal) and realistic losses. (like having to deal with return values 
instead of using exceptions, using only struct instead of templated structs or 
even 
some classes, waving the comfort of namespaces, having hard time with the 
interface 
as a C++ user). New motto for BWAPI1: no portability, max performance, max 
maintenance. (As opposed to slight portability, max performance, no maintenance)

Using BWAPI1 or BWAPI2 on 3rd party compilers now both require you to recompile 
BWAgent.dll. The VC++ specific extensions will _not_ be rewritten. See the 
CodingStandard wiki page, "Portability" headline, point 1. Making BWAPI 
portable 
would most likely not solve your problems. If you use BWTA or other tool 
libraries, 
they would have to be made portable either. The easiest solution is: stick to 
the 
compatible compilers. Use VC++ 2008, and use the spare time (you'd have spent 
with 
porting code and searching for port-related bugs) on your bot.

Original comment by goo...@teabix.com on 1 Jan 2010 at 6:57

• Changed state: WontFix

[GoogleCodeExporter]

I like to link things to make the web more surfable =)
http://starcraftai.rabbitx86.net/index.php?topic=97.0

Original comment by goo...@teabix.com on 1 Jan 2010 at 9:31