Compiling latest trunk with MSVC 2008: not easy

[jcooper]

I just pulled down the latest trunk in order to prepare a patch for submission.  I ran 'premake4 --with-demos vs2008' and then hit 'build' in the resulting solution file. 
1) As mentioned before, the compiler complains that 'precision.h' is missing.  Premake creates config.h.  I think it should also create precision.h, even if it's just an empty header file.  The .lua file seems flexible enough for that.
2) After I created that file, it complained that I don't have <inttypes.h>.  That header didn't gain MS support until vs2010.  Of course, premake4 doesn't provide a vs2010 option...  So I pulled down the msinttypes files from google code. 
3) Then everything compiled, except for the "demo_convex" because its .cpp file is named "demo_convex_cd.cpp" but its "premake4.lua" is just "convex" instead of "convex_cd".
4) Changing the name within the .lua file (and recreating the solution file) leads to the complaint that 'dCollideConvexConvex' and 'dCollideBoxBox' are unresolved externals because they're not exposed by the .dll API. 
Changing to static linking fixes this and finally everything compiles and seems to run.

5) However, if I want to use the .dll interface, I can just ignore the convex_demo.  However, the library still won't run in .dll mode.  It seems that dOU_ENABLED and dATOMICS_ENABLED are now defined in 'config.h' by default regardless of the '--with-ou' option passed to premake.  The library won't compile if they're not defined because of the atomic stuff used in 'util.cpp'.  However, it seems that 'ou/platform.h' has an extra entry: '_OU_TARGET_OS_IOS' (line 40) that isn't accounted for in 'ou/test/outest.cpp' (around lines 8742,8754) so when the .dll initializes, an assert in 'ou/enumarrays.h' (line 166) vomits because there aren't enough elements in the 'm_aetElementArray'.  The target architecture checks also need to be update.  These checks seem to be bypassed when the library is statically linked.  Once the 4 offending enums are fixed, you can finally run "BoxStack" with a dynamically linked version of the library. 

This kind of seems like a lot of hurdles to have sitting in the default trunk configuration for msvc.  I can create a patch (although I don't know what to do about <inttypes.h>), but perhaps someone with commit access could just make the fixes?

jc

[Oleh Derevenko]

OK. Thanks for the investigation. I thought that the problem with <inttypes.h> was because my VS2005 installation was damaged. It's good to know it's VS2010 stuff.

 

I'll take care about arrays in OU tests and inttypes.h inclusion - that's my code.

Oleh Derevenko

-- Skype with underscore

 

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ode-users/-/xK5zqiWR8TMJ.
To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

[Mikko Rasa]

On 20.07.2012 22:56, jcooper wrote:
> although I don't know what to do about <inttypes.h>

That's a tough nut to crack. First I'll note that you probably want
<stdint.h>, which provides the actual types. <inttypes.h> provides some
C-style functions to convert strings to integers.

ODE's internals are written in C++, and C++98 does not know about
<inttypes.h> nor <stdint.h>. C++11 does provide <cstdint>. <cinttypes>
doesn't exist because the string-to-int conversions are handled through
iostreams. However, C++11 support was introduced in VS2010, so this
won't help with earlier versions.

The <inttypes.h> and <stdint.h> headers come from C99. ODE's external
API is C, so we could say it's C99 and get <stdint.h> that way. But
Visual Studio didn't support C99 either prior to the 2010 edition, so
this again won't help.

That leaves the option of shipping our own version of the integer types.
It appears odeconfig.h already defines these; maybe that could be used
in one way or another?

It's also possible to use some template magic to obtain sized integer
types in C++ in a platform-independent way, but that may not be a usable
approach if the types need to be used in a C header.

--
Mikko

[Daniel K. O.]

On 07/20/2012 03:56 PM, jcooper wrote:
> I just pulled down the latest trunk in order to prepare a patch for
> submission. I ran 'premake4 --with-demos vs2008' and then hit 'build'
> in the resulting solution file.
> 1) As mentioned before, the compiler complains that 'precision.h' is
> missing. Premake creates config.h. I think it should also create
> precision.h, even if it's just an empty header file. The .lua file
> seems flexible enough for that.

The lua script has the code to generate the precision.h header when only
one precision is requested. It should not be too hard to handle the case
with two precision builds.

I noticed the other broken stuffs int he MSVC builds some time ago, even
mentioned when I did the precision.h thing. I can't survive long enough
in Windows to try to fix it though.


--
Daniel K. O.

[Oleh Derevenko]

Hi

 

Issues with OU tests and inttypes.h inclusion have been fixed.

 

Also, I've made a workaround to let precision.h be generated for MSVC without specifying --only-single or --only-double. You are free (especially Daniel is) to make further corrections if necessary.

 

Also, there was a code fragment in .lua script like this

  -- special validation for Xcode 
  if _ACTION == "xcode3" and (not _OPTIONS["only-single"] and not _OPTIONS["only-double"]) then
    error(
   "Xcode does not support different library types in a single project.\n" ..
   "Please use one of the flags: --only-static or --only-shared", 0)
  end
with condition testing for --only-single and --only-double but message referring to --only-static and --only-shared. I've changed both to --only-static and --only-shared. Fill free to change it the other way if it is more correct.

[jcooper]

The trunk compiles much more cleanly now.  The convex demo still has some issues, but that's not a big problem.

jc

On Saturday, July 21, 2012 7:32:05 AM UTC-5, Oleh Derevenko wrote: