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:
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.
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.
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?
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.
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.