[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexandre Courbot
Subject: Re: [Adonthell-devel] PPC/Sparc input problem fixed - & Python dependancies problem fixed
Date: Sun, 19 Jan 2003 14:06:05 +0100

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

It's... not great at least :) Adonthell won't compile with automake 1.7.
No big deal - we can simply require 1.6 in our autogen.shs, anyway
distributed versions are automake-independant, so...

> > Oh, and while I'm at it. Another problem. With 0.4 this time. After
> > running 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 and 
> 'cp aclocal.m4 acinclude.m4'. That should do the trick.  

It did, thanks!

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

Not that it would make my task easier, but soon or later we'll have to
switch to GTK 2.0, isn't it? Would dlgedit porting be a huge task?

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

Would be a good idea to make the editors independants of the game
package. At least I think they should have their own configure scripts,
instead of this --enable-tools option that is more confusing than

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

Why not. But my new stuff is in 0.4 and can't be backported. :) It's
becoming quite messy there, guess I'll try to sort things once my finals
are over!

Anyway, this module dependancy is another indication that editors should
be separated from the game. But they still rely on it, and unless we
make use of a shared-library it can't make it. libadonthell anyone? :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]