Get Examples to work on windows

[GoogleCodeExporter]

The Light example already has a VC++ project, although it only works for 
debug+dll libs. we need to :

  - Make it work for 4 combinations : {debug|release} x {dll|static}
  - Create a template for makeproject so that new projects get a VC++ project as well.
  - Run the examples as part of the test-dist step in the autobuild.

Original issue reported on code.google.com by javier.barreiro@gmail.com on 22 Nov 2010 at 10:44

[GoogleCodeExporter]

Original comment by javier.barreiro@gmail.com on 22 Nov 2010 at 10:47

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by javier.barreiro@gmail.com on 22 Nov 2010 at 10:49

• Added labels: OpSys-Windows

[GoogleCodeExporter]

I am almost certain that the static libraries are not built as expected.  The 
file size is only 40KB.  Visual Studio most likely skipped over rebuilding the 
static libraries once it had finished building dynamic.

Java and C++ Light example work for dynamic libraries similar to Unix builds.

Original comment by jasongho85@gmail.com on 24 Nov 2010 at 8:34

• Changed state: Started

[GoogleCodeExporter]

The .a idea to differentiate static libraries is a good idea, although it still 
needs to have the .lib suffix in order for windows executables to run against 
it.  We can do something like System_o.a.lib

Original comment by jasongho85@gmail.com on 24 Nov 2010 at 8:40

[GoogleCodeExporter]

you should be able to link against the .a files without any problem. it's just 
a filename, what's important is that the contents follows the right format.

Original comment by javier.barreiro@gmail.com on 24 Nov 2010 at 11:31

[GoogleCodeExporter]

Debug static and release confirmed working.  Will check Optimized versions next.

Original comment by jasongho85@gmail.com on 25 Nov 2010 at 12:47

[GoogleCodeExporter]

we're having problems getting release-dll to work, the symptom is that 
std::strings created in the client program are not handled well by the europa 
dll.
we changed the options that determine what C++ runtime is linked with the 
library in r6195, but they don't seem to have made a difference.
This thread with comments from the VC++ development team seem to point in the 
same direction though :

http://www.eggheadcafe.com/software/aspnet/35756448/problem-in-stdstring-or-unsu
pported-mix-of-options.aspx

Original comment by javier.barreiro@gmail.com on 9 Dec 2010 at 12:22

[GoogleCodeExporter]

MakeProject:
Use Python uuid module and call tostring method for 32 character id to replace 
VisualStudio project file's GUID and UID.

Original comment by jasongho85@gmail.com on 13 Dec 2010 at 6:31

[GoogleCodeExporter]

All of this is working, except for the c++ project generated by Makeproject, 
which has a number of issues. Jason : let's talk about getting that fixed asap.

Original comment by javier.barreiro@gmail.com on 16 Dec 2010 at 2:31

[GoogleCodeExporter]

Using MakeProject

Requires python 2.5 or better

python %PLASMA_HOME%\bin\makeproject %project%

Using visual studio project created:
  For optimized (debug/release) versions,
set config manager checkbox for build
add debugging arguments in project properties

  For Static (debug/release) versions
set config manager checkbox for build
add debugging arguments in project properties
add module%project%.cc to source

Original comment by jasongho85@gmail.com on 16 Dec 2010 at 7:59

[GoogleCodeExporter]

autobuild on windows is fully working with tests for makeproject and examples 
as of r6239, the windows build is ready to be released.

Original comment by javier.barreiro@gmail.com on 17 Dec 2010 at 7:49

• Changed state: Fixed