I tested out this version but ran into some problems…
I’m running Linux RHEL4 and the makefiles do not work for me, have to change all occurences of
else ifeq to two separate lines to make my older version of make happy. Where should I report this (or where do I send the patch?).
Also, just typing make only compiles one file, have to type make all to build everything, but perhaps that’s also something that has to do with my older version of make, I’m not sure…
Collada DOM 2.0 seems to have been released, but no sound of that here, strangely enough.
I’m waiting to get updated documentation on the wiki before I make an announcement.
Regarding the make problems, the DOM build now requires GNU make 3.81, which is about two years old I think. You can find out which version you have with “make --version”. I believe that all recent versions of the major distros will have GNU make 3.81 available. Check your package manager. The problem of make compiling only one file is almost certainly because you have an older version of make, or maybe a non-GNU version of make. I have the line “.DEFAULT_GOAL := all” in the makefile and when I do a ‘make’ it builds everything.
My preference is definitely to stay with GNU make 3.81 for our make build system. If this causes you a lot of problems then let me know.
We are running lots of machines with RHEL4/CentOS4, the make version on those are 3.80 =(.
Upgrading the base utilities of these systems are not always an easy option, although possible.
I’ll see if I can figure out what changes would be needed to the makefile to make it work for me, if there are only minor changes perhaps they could be folded into the main repository. If not I’ll just keep patching it on my side.
We are running lots of machines with RHEL4/CentOS4, the make version on those are 3.80 =(. Upgrading the base utilities of these systems are not always an easy option, although possible.
But you don’t have to build the DOM on every machine, right? You could build it on one machine and then distribute the headers & binaries to the other machines so that they could compile your DOM client app. This is what I did at the last company I was at. I built the DOM on my machine and checked in the binaries and headers to revision control. When a developer checked out our code he would get those files, so he’d have everything needed to compile our DOM client code, but he didn’t have to build the DOM himself.
I’ll see if I can figure out what changes would be needed to the makefile to make it work for me, if there are only minor changes perhaps they could be folded into the main repository.
This might be reasonable. It depends on the scope of the changes. I rely on some advanced features of make (like eval) in order to reduce the size of the make code and make it more maintainable.
I’m not sure if you’ve done this already, but check your package manager to see if make 3.81 is available. Wikipedia reports that the last release of RHEL 4, 4.6, is from November of last year. Since make 3.81 is about two years old RHEL 4 might have a suitable rpm available.
I am testing the new release, never got around grabbing a copy from SVN, I am having all kinds of troubles trying to build with MinGW using make, I was wondering if you guys would be interested on a patch for building on MinGW/Cygwin?.
Also, and I hope this is the right place to ask, getInit_from_array is no longer a member of domFx_surface_common, how can I access that array now?
Yes, I’m very interested in this! In fact my goal was to completely remove the Visual Studio project files and build the DOM solely from make on all platforms, using a mingw-provided version of GNU make 3.81. Windows is the only platform not on make now. My vision for this is that you could use make on Windows to build using a variety of different compilers, like VS 2003, 2005, 2008, the mingw gcc compiler, etc. Unfortunately I needed to ship DOM 2.0 and didn’t have time to implement this.
I was hoping that our current make architecture would mostly work on Windows with cygwin. I’m sorry to hear you’re having so much difficulty. I’d gladly accept any patches to make our support on that platform better. My hope is that the changes could fit within the current make setup without requiring radical modifications.
Also, and I hope this is the right place to ask, getInit_from_array is no longer a member of domFx_surface_common, how can I access that array now?
My apologies for this breakage! This is documented, along with many other breakages, on the DOM backward compatibility page on the wiki. You would now call this as surface->getFx_surface_init_common()->getInit_from_array();
