Stefan Walter | 1 May 17:01 2006
Picon

Re: ATTN Maintainers: request for upgrade to GLib 2.6 and Gtk 2.6

Hi,

Roland Clobus, 30.04.06, 21:54h CEST:

> I've just committed a patch that adds the second set of #ifdefs in the 
> code for the use of GLib 2.6 code (that was needed, because the 
> newest version of libgnome had things we used deprecated)
> Previously GLib 2.6 was only used for the persistent settings, now it 
> is also used for the commandline parsing.
> 
> Can the minimum required version of GLib be raised from 2.4 to 2.6, or 
> will we lose support for some platforms? (GLib 2.6.0 and Gtk 2.6.0 
> were released on 2004-12-16)
> 
> Also, I've found some usefull new functions in Gtk 2.6, can the 
> minimum version of Gtk also be raised to 2.6?

In the FreeBSD ports collection, GLib is at 2.10.2 now, GTK at 2.8.17, so
that's OK over here.

Stefan
Brian Wellington | 1 May 20:26 2006

Re: ATTN Maintainers: request for upgrade to GLib 2.6 and Gtk 2.6

On Sun, 30 Apr 2006, Roland Clobus wrote:

> Can the minimum required version of GLib be raised from 2.4 to 2.6, or
> will we lose support for some platforms? (GLib 2.6.0 and Gtk 2.6.0
> were released on 2004-12-16)
>
> Also, I've found some usefull new functions in Gtk 2.6, can the
> minimum version of Gtk also be raised to 2.6?

Fedora Core 4 and 5 use 2.6, and I believe everything older is mostly 
unsupported.  I think this change should be ok now.

Brian

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Giancarlo Capella | 2 May 09:37 2006

Visual resources patch

I've just uploaded the patch #1480221 to obtain a visual representation of resources. I didn't have time to
redraw the icons, but I finally got the code that satisfy me enough.
In the resourses box for the player, the resources are drawn as single icons. There are two ways for how the
icons are drawn: separated if there is enough space, or overlapped if there are too many icons for the
available space. It's easy to understand if you have at least two resources of the same type and shrink the
vertical frame.

Developing this patch, a number of doubt rised.
1. Is it ok to overlap the icons or is better to let them separated? In the latter case some code can be stripped away.
2. If the space available is not enough, is it ok to let the icons "disappear" or is better to fall in a
<number><icon> representation?
3. Now the icons are shown where the labels were before. An alternative is to draw the icons in a consecutive
manner, overlapped or not. This may lead to a space optimization, but may also be more confusing. This kind
of representation can be useful playing with open hands (if and when it will be implemented), to draw other
players' resources.

In the next days I'll try to draw new icons based on yours suggestions, and I'll try both 16x16 and 24x24
bitmaps to see what's better.
But I like current icons, so I think to keep them as unofficial patch, beside the future official ones. :)

The patch uploaded has to be applied to pioneers/client/gtk, with the PNGs copied in pioneers/client/gtk/data.

Gianx

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
(Continue reading)

Bas Wijnen | 2 May 20:17 2006
Picon

Is a minimum automake version of 1.9 ok?

Hello,

This afternoon I fixed the single Makefile patch so that it actually works.
However, I found that it requires a minimum automake version of 1.9, because
versions before that consider files in a different directory than the
Makefile.am a bug.

Is it a problem to require automake 1.9?

I think a single Makefile would be an improvement.  For those who are not
familiar with the problems, I quote the automake manual[1]:

	If you've ever read Peter Miller's excellent paper, Recursive Make
	Considered Harmful, the preceding section on the use of subdirectories
	will probably come as unwelcome advice. For those who haven't read the
	paper, Miller's main thesis is that recursive make invocations are
	both slow and error-prone.

and I would advise to read Miller's paper, which is available from
http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html

At the time of writing the paper, automake was not able to use a non-recursive
method, so he advises to not use it.  However, now that it can use this
method, I don't think this advice should still be followed.

Thanks,
Bas

[1] http://www.gnu.org/software/automake/manual/html_node/Alternative.html

(Continue reading)

Stefan Walter | 2 May 21:03 2006
Picon

Re: Is a minimum automake version of 1.9 ok?

Hi,

Bas Wijnen, 02.05.06, 20:17h CEST:

> This afternoon I fixed the single Makefile patch so that it actually works.
> However, I found that it requires a minimum automake version of 1.9, because
> versions before that consider files in a different directory than the
> Makefile.am a bug.
> 
> Is it a problem to require automake 1.9?

That should be OK with FreeBSD.

Regards,
Stefan
Steve Langasek | 3 May 01:05 2006
Picon

Re: Is a minimum automake version of 1.9 ok?


On Tue, May 02, 2006 at 08:17:51PM +0200, Bas Wijnen wrote:

> This afternoon I fixed the single Makefile patch so that it actually works.
> However, I found that it requires a minimum automake version of 1.9, because
> versions before that consider files in a different directory than the
> Makefile.am a bug.

> Is it a problem to require automake 1.9?

Given that only developers should ever need to run automake (when building
out of svn, or rolling official tarballs), I don't see any problem at all
with this -- anyone who doesn't already have automake1.9 available for their
platform of choice should be able to download and install it locally with
ease.

FWIW, I'm not really sold on the benefits of the single-makefile approach;
I'm familiar with the "considered harmful" paper, but there are trade-offs
with each approach, and I haven't found any problems with the existing
structure -- so this is very much a "ain't broke, don't fix it" scenario for
me.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon <at> debian.org                                   http://www.debian.org/
Bas Wijnen | 3 May 09:34 2006
Picon

Re: Is a minimum automake version of 1.9 ok?

On Tue, May 02, 2006 at 04:05:43PM -0700, Steve Langasek wrote:
> > Is it a problem to require automake 1.9?
> 
> Given that only developers should ever need to run automake (when building
> out of svn, or rolling official tarballs), I don't see any problem at all
> with this -- anyone who doesn't already have automake1.9 available for their
> platform of choice should be able to download and install it locally with
> ease.

Good point.

> FWIW, I'm not really sold on the benefits of the single-makefile approach;
> I'm familiar with the "considered harmful" paper, but there are trade-offs
> with each approach, and I haven't found any problems with the existing
> structure -- so this is very much a "ain't broke, don't fix it" scenario for
> me.

IMO there are two main problems with the multiple Makefiles:

- They don't get dependencies right.  editor/pioneers-editor depends on
  common/libpioneers.a, but it is unable to make sure it gets built.  Also, it
  cannot see if it will be rebuilt.  So when doing a multithreaded build, it
  may happen that both of them are out of date (but the lib does exist
  already) and both get rebuilt, but the editor happens to get linked to the
  old version, because the new one wasn't ready yet.
  These things don't happen in a single-threaded build, because we carefully
  chose the order that things are built in that case.  But that is very
  fragile, and shouldn't be relied upon (because it breaks multi-threaded
  builds ;-) ).

(Continue reading)

Roland Clobus | 4 May 08:00 2006
X-Face
Picon
Picon

Re: Single Makefile (Was: Is a minimum automake version of 1.9 ok?)

On Wednesday 03 May 2006 09:34, Bas Wijnen wrote:
> On Tue, May 02, 2006 at 04:05:43PM -0700, Steve Langasek wrote:
> IMO there are two main problems with the multiple Makefiles:
> 
> - They don't get dependencies right.  editor/pioneers-editor depends 
on
>   common/libpioneers.a, but it is unable to make sure it gets built.  
Also, it
>   cannot see if it will be rebuilt.  So when doing a multithreaded 
build, it
>   may happen that both of them are out of date (but the lib does 
exist
>   already) and both get rebuilt, but the editor happens to get 
linked to the
>   old version, because the new one wasn't ready yet.
>   These things don't happen in a single-threaded build, because we 
carefully
>   chose the order that things are built in that case.  But that is 
very
>   fragile, and shouldn't be relied upon (because it breaks 
multi-threaded
>   builds ;-) ).

So this means we don't support 'make -j'.
On my computer (after a 'make clean') make takes about 30 seconds.
Why should I need -j?
The dependencies are currently correct, the common directories are 
entered first in SUBDIRS, before the other directories that need it.
I don't consider that fragile.

(Continue reading)

Bas Wijnen | 4 May 08:53 2006
Picon

Re: Re: Single Makefile (Was: Is a minimum automake version of 1.9 ok?)

On Thu, May 04, 2006 at 08:00:07AM +0200, Roland Clobus wrote:
> On Wednesday 03 May 2006 09:34, Bas Wijnen wrote:
> > On Tue, May 02, 2006 at 04:05:43PM -0700, Steve Langasek wrote:
> > IMO there are two main problems with the multiple Makefiles:
> > 
> > - They don't get dependencies right.
> 
> So this means we don't support 'make -j'.

Indeed.

> On my computer (after a 'make clean') make takes about 30 seconds.
> Why should I need -j?
> The dependencies are currently correct, the common directories are 
> entered first in SUBDIRS, before the other directories that need it.
> I don't consider that fragile.
> 
> Is 'make -j' a requirement for a special build of Pioneers you are 
> preparing?

No, it isn't.  It's just something that should work if we have the build
system in order.  The fact that it doesn't is a bug IMO.  There are
workarounds ("don't use -j"), but it's still a bug.

> > - They're asking for code duplication.
> 
> The ($topdir)/rules.make was needed because we didn't know enough of 
> the autotools. Since I've read the manual for the autotools, the 
> contents of the rules.make was integrated into configure.ac.

(Continue reading)

Giancarlo Capella | 4 May 09:58 2006

While in Makefile season...

Only some suggestion while working on Makefile.

A friend of mine, quite new to C compilation under linux, was a little bit confused for the results he got.
Briefly, he got this while running configure:

...
checking for GLIB2... yes
checking for GLIB2_6... yes
checking for GTK2... checking for OLD_GTK2... checking getopt.h usability... yes
checking getopt.h presence... yes
...

and then obviously:

Build graphical client             no

It was missing the GTK2 dev libs, but why the result of check was neither "yes" nor "no"?
And what about adding the note "GTK2 missing" in the final summary? GTK2 isn't really needed for a
compilation without errors, but it compiles only the server. He didn't notice and it was difficult for him
to understand.
Maybe it should be sufficient to write this dependence in the README.

At the end, why he didn't use a binary release? He use SuSE and he told me he didn't find a binary package for it.
I don't know if it's true or not.

Regards
Gianx

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
(Continue reading)


Gmane