Compiling DOM-2.0 under Debian Sarge

Dear folks,

I’m currently trying to compile the Collada-DOM 2.0 under Debian Sarge 3.1, using g++ 3.3.5.
However, I get a type conversion error. The problem is clearly demonstrated in this small test:

Collada-DOM-2.0/dom$ uname -a
Linux ThuBi-Blue 2.6.8-2-386 #1 Thu May 19 17:40:50 JST 2005 i686 GNU/Linux

Collada-DOM-2.0/dom$ g++ --version
g++ (GCC) 3.3.5 (Debian 1:3.3.5-13)
Copyright © 2003 Free Software Foundation, Inc.
Dies ist freie Software; [...]

Collada-DOM-2.0/dom$ cat mytest.cpp
#include <dom/domCg_param_type.h>

Collada-DOM-2.0/dom$ g++ -Wall -g -DDEBUG -DDOM_INCLUDE_LIBXML -Iinclude -Iinclude/1.4 -c -o mytest.o mytest.cpp
In file included from include/1.4/dom/domCg_surface_type.h:25,
                 from include/1.4/dom/domCg_param_type.h:21,
                 from mytest.cpp:1:

include/dae/daeSmartRef.h: In copy constructor `
   daeSmartRef&lt;T&gt;::daeSmartRef(const daeSmartRef&lt;T&gt;&) [with T = domCg_param_type]':
include/1.4/dom/domCg_setparam_simple.h:60:   instantiated from here
include/dae/daeSmartRef.h:59: error: cannot convert `domCg_param_type*' to `
   const daeRefCountedObj*' for argument `1' to `void checkedRef(const daeRefCountedObj*)'

include/dae/daeSmartRef.h: In destructor `daeSmartRef<T>::~daeSmartRef() [with T = domCg_param_type]':
include/1.4/dom/domCg_setparam_simple.h:60:   instantiated from here
include/dae/daeSmartRef.h:36: error: cannot convert `domCg_param_type*' to `
   const daeRefCountedObj*' for argument `1' to `void checkedRelease(const daeRefCountedObj*)'

Clearly, when the error is reported, the compiler does not know yet that domCg_param_type is derived from daeRefCountedObj, so the error itself is correct. The fact however that the related functions are implemented inline seems to cause the compiler to create code early, which is contrary e.g. to VC++ 2005, where the same code works just fine.

Any ideas? :?:
I guess that the problem can be worked-around by #including <dom/domCg_setparam_simple.h> manually in the right places, but I’m looking for a more proper solution.

Many thanks in advance!

Clearly, when the error is reported, the compiler does not know yet that domCg_param_type is derived from daeRefCountedObj, so the error itself is correct.
You think so? When I try building that same program (with just the single #include) I don’t get any such errors. I’m using gcc 4.1.3. Since both the newer version of gcc and Visual Studio don’t emit any errors it would lead me to believe the code is ok, and it’s a bug in the older gcc. Not really sure though, I didn’t look into it in depth.

Sounds like you might have to #include some extra files as you suggest to get this working. The DOM does compile for you though, right?

Also just fyi, you don’t need “-DDOM_INCLUDE_LIBXML” in client apps.

Steve

Hi Steve,

thank you very much for your quick reply! :slight_smile:

You are right, and I should have been more careful with my diagnosis: I just installed g+±3.4 for a quick test, and it compiled the same code just without problems. So I’ll probably just upgrade my box to a recent version of Ubuntu or Debian.

The DOM does compile for you though, right?

Also just fyi, you don’t need “-DDOM_INCLUDE_LIBXML” in client apps.

Yes, thanks, but it was actually the DOM, not a client app that I was trying to compile, I just tried to isolate and reproduce the issue in a custom minimal test file.

Btw., I read somewhere else that you’re planning to remove the Visual Studio project files and to compile everything with Makefiles even under Windows. Well, I use SCons (see http://www.scons.org for details) for all my builds on all platforms (currently that’s only Windows and Linux, MacOS follows). SConstruct and SConscript files are very short and to the point, and writing them is very easy. In this case I wrote some for limxml2 and pcre, too. However, in such cases one has to figure out the basics of a generic built by reading the Makefiles, or even worse, monitor the changes that a run of the configure script causes. For the DOM, I therefore just looked at the VS project files in order to learn the relevant build details - the VS project files are much easier to follow than the Makefiles.
Thus, I’d be happy if you not removed them from the DOM releases. Even better, have you considered SCons as the main build system for the DOM? :wink:

Regarding SCons, I’m going to be moving off of DOM work in the near future so it’s unlikely I’ll be making any more big changes to the DOM’s build system.

However I have some other Collada-related projects that I may be working on and I’ll probably be thinking a lot about build systems. Overall I’m pretty happy with the DOM’s make build actually. It has a ton of nice features in comparison with other make build systems I’ve used, and the dependency tracking works perfectly. It’s also easier to use/maintain and more powerful than the Visual Studio build.

But make has a whole host of problems stemming from the goofy semantics of the make language. Using a better language (Python’s light years ahead of make in this regard) in the build system would make things way easier.

Here are the main things I want in a build system:

  • The build system should be based on writing a program to do the build, like make. Config files (a la Visual Studio) are unlikely to offer the flexibility I want.
  • I should be able to build on all platforms using the same build system.
  • It should be easy to automate the entire build system from the command line.
  • I want to be able to implement all the features I currently have in the DOM’s make build. Things like parallel builds, compiling just a single file, building multiple configs (e.g. both debug and release) in a single command… stuff like that.

Even though it’s unlikely the DOM will switch over, I’ll definitely check SCons out for my future projects.

Steve

You probably want to look at CMake too if you’re not aware of it.

http://en.wikipedia.org/wiki/CMake

Yeah CMake is interesting. Since it’s based on generating IDE-specific build files it seems like you’d be constrained in terms of what you can implement by the IDEs you want to support, but I don’t have much experience with it.

I’ll probably take a look at Ant also.