Removing Sumo? WAIT! Re: [Bf-committers] CVS commit: blender/source/gameengine/Ketsji KX_SumoPhysicsController.cpp KX_SumoPhysicsController.h

[bf-committers@blender.org]

On Tue, Nov 05, 2002 at 02:09:42PM +0100, Maarten Gribnau wrote:
> This was a CVS remove, the files can be brought back in no time. I agree with
> you that the remove was not necessary and that there are other solutions
> although the controller was referencing a non-existing file.

Do you by any chance still have the compiler log showing which files were
missing?

In my test I was able to get all the Sumo stuff to compile. There were no
missing files, just some outdated references because of the apparent
removal of the toplevel blender/source/sumo directory. The Sumo
files were all still in blender/source/gameengine/Physics/Sumo directory.

> My main focus was
> to get a compiling tree right out of the box and I thought the sumo move would
> not happen in the near future. Hence the removal. Are you planning to do the
> SUMO reimplementation soon?

No, I am not, but with the current code/Makefile structure it was maybe 1-2 hours
work to test out to see what was missing with Sumo. The more removed Sumo becomes
from the codebase, the more difficult it is to test it out. My concern was that
a total excising of Sumo code will make it very unlikely to ever be integrated
into Blender again (because Blender and its make system will certainly evolve,
and removed Sumo files will never be looked at, much less updated, by developers).

As for me, I am managing all of the Blender sourcecode locally in my own Aegis
repository and syncing manually with CVS, so nothing that happens in CVS can
negatively impact my work. The removal of Sumo stuff therefore doesn't affect
my (to date very minimal and experimental) work in this direction, but it might
discourage other potential developers, with more time, from working on this project.

Since the stuff is already removed, and the focus is now, as you say, on
getting a buildable version, I'd say just leave the stuff removed. After
the build system is stable then you/I/someone else can re-add the Sumo
files at the appropriate places (determining those "appropriate places"
is difficult for new developers, like me, which is why I also am paraoid
about removing almost-working code) and make a conditional compile for Sumo
with the new build system.

> The depend kludge solution works but in the long run it would be nice if the
> physics (and the sound system too) could be loaded dynamically so that depend
> kludges are not necessary. 

Sounds interesting. What do you mean by loaded dynamically? As in, real
dynamic libraries? Does Blender currently build any dynamic libraries at
all? Hm, cross-platform support for dynamic libraries is certainly a fun
can of worms to open. I know "libtool" is designed to deal with exactly
this problem (building shared libraries in a platform-independent way),
but I don't know exactly which platforms it supports (I know GNU/Linux is
supported).

> BTW My commit emails always come the next day although CVS tells me it is
> sending the mails when I commit. Anybody have a clue how to fix that?

Ton's been adjusting some mailing list parameters, maybe it has something
to do with that.

-Norman