Re: [Adonthell-devel] PPC/Sparc input problem fixed - & Python dependancies problem fixed

[Kai Sterker]

On Fri, 17 Jan 2003 23:44:24 +0100 Alexandre Courbot wrote:

> Maybe. I'd be for it, but I have already enough problems with automake
> 1.7! ;) Plenty of errors that forced me to get back to 1.6. They could
> keep some compatibility at least!

Pfff, compatibility is for losers :P.

Seriously, is it that bad? Haven't noticed that 1.7 was out, so I
haven't tried yet.

 
> What are the features of new autoconfs? From which versions? I guess
> it can only be better than our tests that doesn't work everywhere :)

Talking of 2.53 (or .54). Not sure what Python checks are covered. But
looking at the .m4 scripts (or the docs) should reveal that. It's not
the most pressing matter though, I think.


> In C++ side you mean? Yeah, that wouldn't hurt anyway - and would only
> be nice programming.

Yeah. Of course, this only applies to classes that don't have any
constructor at all.


> Oh, and while I'm at it. Another problem. With 0.4 this time. After
> running autogen.sh and configure I end with an incorrect libtool which
> doesn't set:
[...]
> Do you remember what you did to fix that? :)

Delete acinclude.m4 and aclocal.m4. Then run autogen.sh and 
'cp aclocal.m4 acinclude.m4'. That should do the trick.  


> Oh, other questions. I have errors while compiling the tools in 0.3,
> but nothing serious - I'll fix it (dlgedit doesn't use std::
> everywhere as it should).

O. Thought I tested that with g++ 3.2 too. Sorry!


> Still, I'd like to know which version of GTK
> you use so I can use the same for my tools. Are you using 1.2 or 2.0?

Still 1.2, because switching to 2.0 would mean updating all the lists
and multiline edit boxes. And I'm not sure whether that would be worth
the trouble. Of course, if GTK 2.0 would make your task easier somehow,
then I would make the changes.


> Why not moving the new dlgedits to 0.4, since we should concentrate on
> that now?

Actually, I was thinking whether we should move the tools into a module
of their own.

Concerning the 0.4 branch: well, that's partly outdated. The event stuff
in 0.3 is newer, as is py_object since thursday. Not to mention all
those small tweaks to support other OSes and non-intel hardware.

So I personally wouldn't feel very well to continue developing in that
branch. I think the proper procedure would be to continue development in
the main branch. When making fixes to 0.3 later on, we could use an
additional branch for them. At least that's the way it's done in the CVS
book.

Kai