pio-temporary — Temporary replacement for all lists until issues resolved

Re: [Pio-temporary] Dealing with annoying disconnects

[Bas W. <sh...@fm...>]

On Tue, Jan 31, 2006 at 05:43:13PM -0500, Rob Renaud wrote:
> What about when a player loses connection?  How long is the timeout?=20
> Clean disconnects are fine, dropped internet connections are not.

This should be reproducible by unplugging the network on a client machine. =
 In
that case, the computer doesn't know about the disconnect.  Pinging it might
help (to let the kernel know the host is down).  Pioneers cannot help here,
it's the OS which needs to know that the connection no longer exists.  When=
 it
knows, it will instantly notify the program.

A feature to move players and viewers around, as in "Gorbachev is now a
viewer, shevek is now player 2" would be very useful.  This should obviously
be commands to the server.  There are some plans to change the way things w=
ork
with the server (in particular, to have only one server, the console one, a=
nd
have a Gtk front-end for it, instead of a Gtk server as it is now).  Howeve=
r,
I think having this feature is useful, and it may be a bad idea to wait for=
 us
to have time to do the server rewriting thing.

However, for a permanent solution there should be a good plan about the adm=
in
interface IMO.  The current admin thing (does it work at all, actually?)
shouldn't be the base of it, it should just be redesigned with proper design
goals in mind.

Thanks,
Bas

--=20
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Re: [Pio-temporary] Dealing with annoying disconnects

[Rob R. <rr...@gm...>]

What about when a player loses connection?  How long is the timeout?=20
Clean disconnects are fine, dropped internet connections are not.

On 1/31/06, Roland Clobus <rc...@us...> wrote:
> On Monday 30 January 2006 04:13, Rob Renaud wrote:
> > What is the best way to handle a player getting disconnected?  The
> > ghost of the player stays around for quite awhile (seems like 15
> > minutes or so) even after the player reconnects and gets the new
> nick
> > with an underscore appended.  Is there some way for the admin to
> > forcibly kill the ghost?
> >
> > I am willing to hack the admin console to add such a feature, if
> it's
> > desired.  Or it might be a good idea to let people change to already
> > taken names, if explicitly allowed in the game settings?
>
> When a player gets disconnected, his name stays visible in the client,
> with some extra squares in the icon. When any player reconnects, he
> will take over the game. If this does not happen, you've stumbled
> across a bug.
>
> If a player disconnects in his turn, the game will wait until a
> reconnect is made. If a player disconnects when it is someone else's
> turn, the player will skip turns until a reconnect.
>
> I cannot reproduce the situation you describe. When a player
> disconnects, the reconnecting player will not get an underscore
> appended to its name on my computer.
>
> Which version of the client and server are you using?
>
> Regards,
> Roland Clobus
>

Re: [Pio-temporary] Dealing with annoying disconnects

[Roland C. <rc...@us...>]

On Monday 30 January 2006 04:13, Rob Renaud wrote:
> What is the best way to handle a player getting disconnected?  The
> ghost of the player stays around for quite awhile (seems like 15
> minutes or so) even after the player reconnects and gets the new 
nick
> with an underscore appended.  Is there some way for the admin to
> forcibly kill the ghost?
> 
> I am willing to hack the admin console to add such a feature, if 
it's
> desired.  Or it might be a good idea to let people change to already
> taken names, if explicitly allowed in the game settings?

When a player gets disconnected, his name stays visible in the client, 
with some extra squares in the icon. When any player reconnects, he 
will take over the game. If this does not happen, you've stumbled 
across a bug.

If a player disconnects in his turn, the game will wait until a 
reconnect is made. If a player disconnects when it is someone else's 
turn, the player will skip turns until a reconnect.

I cannot reproduce the situation you describe. When a player 
disconnects, the reconnecting player will not get an underscore 
appended to its name on my computer.

Which version of the client and server are you using?

Regards,
Roland Clobus

Re: [Pio-temporary] Dealing with annoying disconnects

[LT-P <LT...@LT...>]

Le lun 30 jan 2006 03:13:26 CET, Rob Renaud <rr...@gm...> a écrit:

> What is the best way to handle a player getting disconnected?
Why not a kick message which would drop the connection data of the target
user, in order to let a new one (human or AI, which could be useful to
replace a leaving human player) takes his place ?

LT-P

--
Seals are cute, kiss them

[Pio-temporary] Dealing with annoying disconnects

[Rob R. <rr...@gm...>]

What is the best way to handle a player getting disconnected?  The
ghost of the player stays around for quite awhile (seems like 15
minutes or so) even after the player reconnects and gets the new nick
with an underscore appended.  Is there some way for the admin to
forcibly kill the ghost?

I am willing to hack the admin console to add such a feature, if it's
desired.  Or it might be a good idea to let people change to already
taken names, if explicitly allowed in the game settings?

Re: [pio-develop] Re: [Pio-temporary] Problems running Pioneers-0.9.40 on windows

[Don S. <do...@se...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland Clobus wrote:
> In that case, the path to the Gtk+ runtime could not be found.
> Sometimes the Gtk+ runtime installer does not update the path. 
> (http://gimp-win.sourceforge.net/stable.html)
> 
> Could you add 'C:\Program Files\Common Files\GTK\2.0\bin' (without the 
> quotes) to your path?

Roland did you see my last email about the right registry entries to
look in?

- --
Don Seiler
do...@se...

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFC87F041
Fingerprint: 0B56 50D5 E91E 4D4C 83B7  207C 76AC 5DA2 FC87 F041
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDyuVIdqxdovyH8EERAoQkAJ49kUqq+KDEylRQTQjd0eePAi83fwCgjop3
1RpWs1memx0DgNoSRQRzR+Y=
=Z38d
-----END PGP SIGNATURE-----

Re: [Pio-temporary] Problems running Pioneers-0.9.40 on windows

[Roland C. <rc...@us...>]

On Sunday 15 January 2006 21:59, Rob Renaud wrote:
> I downloaded the latest pioneers release for windows from
> 
> 
http://prdownloads.sourceforge.net/pio/Pioneers-0.9.40-setup.exe?download
> 
> However, when I try to run it, I get a dialog that says
> 
> pioneers.exe - Unable To Locate Component
> 
> This application has failed to start because libgdk-win32-2.0-0.dll
> was not found.  Re-installing the application may fix this problem.

In that case, the path to the Gtk+ runtime could not be found.
Sometimes the Gtk+ runtime installer does not update the path. 
(http://gimp-win.sourceforge.net/stable.html)

Could you add 'C:\Program Files\Common Files\GTK\2.0\bin' (without the 
quotes) to your path?

Regards,
Roland Clobus
Developer for Pioneers

[Pio-temporary] Problems running Pioneers-0.9.40 on windows

[Rob R. <rr...@gm...>]

I downloaded the latest pioneers release for windows from

http://prdownloads.sourceforge.net/pio/Pioneers-0.9.40-setup.exe?download

However, when I try to run it, I get a dialog that says

pioneers.exe - Unable To Locate Component

This application has failed to start because libgdk-win32-2.0-0.dll
was not found.  Re-installing the application may fix this problem.

Re: [Pio-temporary] Ideas for AI playing development cards

[Roland C. <rc...@us...>]

On Sunday 02 October 2005 22:21, Brian Wellington wrote:
> On Sat, 1 Oct 2005, Roland Clobus wrote:
It's now a few weeks later, but I haven't stopped thinking about this, 
I was working on the MinGW port.

> > Year of Plenty:
> > Current: will be played anytime the bank has at least 2 resources. 
If
> > the bank does not contain anything the AI likes, it will request 
the
> > resources for a road, and if the bank is too empty, it will just 
pick
> > something at random.
> >
> > Proposed: the bank must have at least 2 resources. If the bank 
does
> > not contain anyting the AI likes, determine whether it is possible 
to
> > get enough resources to perform a maritime trade to get the 
resource
> > the AI needs (in the next turn). If not, determine whether the AI 
is
> > allowed to place a road [*1] and the resources are in the bank, 
and
> > request that. If all fails: don't play this card yet.
> 
> I'm a bit confused by this logic.  If the bank doesn't contain any 
> resources the AI wants, it doesn't matter whether the AI can get 
enugh 
> resources to be able to perform a maritime trade next turn, since 
there's 
> a good chance there still won't be any resources it wants, and it 
also 
> means the AI is more likely to have over 7 cards.

You're right. The AI takes two risks with that scenario. 

> I wonder if it would be possible to figure out if the AI is 1-2 
cards 
> short of a city/settlement/road it wants to build, and only play the 
card 
> in that case.

New proposal: the bank must have at least 2 resources. Determine 
whether the AI needs one or two cards to buy something, and the 
resources are in the bank. If not, determine whether the AI is 
allowed to place a road [*1] and the resources are in the bank, and
request that. If all fails: don't play this card yet.

> > Monopoly:
> > Current: will be played when the other players have at least six
> > resources cards in total. If the AI doesn't need anything in
> > particular, it will pick the resource that all players have the 
most
> > of.
> >
> > Proposed:  will be played when the other players have at least six
> > resources cards in total. If the AI doesn't need anything in
> > particular, don't play it yet.
> 
> Agreed, although I wonder if the AI should take into account the 
number of 
> cards.  For example, if the AI wants a lumber, and will only get 1 
lumber 
> by playing monopoly, but could get 10 brick, taking the brick would 
be a 
> much better idea, since it could do a 4:1 (or better) trade and 
still come 
> out way ahead.

I think the minimum number of resources cards in the hands of the 
other players was added to prevent the monopoly card to be played too 
early. If the AI would gain only one card, would it be worth it to 
play the card? (I think only when it will result in the final victory 
point)

Because the AI can see how many resources are still in the bank, 
it can make an accurate guess of the profits of playing the card.
If the AI wants a specific resource, it could alternatively try to get 
it from maritime trade, after playing the Monopoly card for the 
abundant resource (but it must be sure that it gets enough cards to 
perform the trade and to buy something).

> > Gold:
> > Current: when the AI does want something, get it. Otherwise, start
> > emptying the bank starting from the first resource.
> >
> > Proposed: when the AI does want something, get it. Otherwise, 
start
> > emptying the bank starting from the resource that has the best
> > maritime trade ratio.
> 
> Unlike the dev cards, gold can't be deferred until later, so there 
might 
> be situations where the AI doesn't want anything because it can, for 
> example, already build a settlement.  It might be worth it to figure 
out 
> what the AI will do first, and if its first action is to buy 
something, 
> re-evaluate what it would want after buying it, then choose that, 
falling 
> back to something like your suggestion afterwards.  This might be 
too 
> complicated, though, and your idea would still help.

Sounds like a good idea. It is more complicated though.
Perhaps this can be changed in two steps.

Roadbuilding: see task #120371.

Regards,
Roland Clobus

[Pio-temporary] Bug [ 1294598 ] game crashed after playing invention card

[Roland C. <rc...@us...>]

Hello re...@we...,

You wrote:
The game crashed after playing an invention card and, leaving values 
untouched (not choosen any resources)
---
It is not clear enough to me what happened exactly. I cannot reproduce 
the crash on my computer, so that leaves me with a whole lot of 
questions to ask you:

I understand you played an invention card (Erfindung, Year of Plenty).
I assume you saw the window where you can choose the two resources.
What did happen next? Did the server crash, or the client?
Did you try to close window? If so, did you use the Ok button, or a 
close button in the window?

Could you describe in a little bit more detail what did lead to this 
crash? Did it happen a second time? Which version are you using, and 
what Linux distribution do you use?

Regards,
Roland Clobus
Developer for Pioneers

BTW: You can respond in German if you like.

Re: [Pio-temporary] Regarding GGZ (RFE #641445)

[Bas W. <sh...@fm...>]

On Sat, Oct 01, 2005 at 05:43:31PM +0200, Roland Clobus wrote:
> Hello all,

Hi,

> For a while I had been thinking about using GGZ for a chat room in the=20
> meta-server. GGZ offers functionality to join and leave games, start=20
> new games, add computer players, chat before a game starts, etc.
>=20
> But I'm running Debian, and GGZ in Debian has for a long time been an=20
> old version, and recently it has been removed from the Debian=20
> repository.
>=20
> So what should I do with that old feature request? Shall I close it,=20
> or is there another alternative that is worth looking into?

I don't know about others (and actually I don't know about GGZ either), but=
 if
GGZ is the best solution, then it should be packaged for Debian again.  If
there are plans to use it, I can look into that.

> I have an alternative for a chat room in the meta-server:
> If there is a .game with only one land tile, and a required number of=20
> players of more than two (or perhaps 99), that game can never really=20
> be started nor finished, and thus serve as a kind of chat room.

I just noticed that games with 0 players can also be started, which make
everyone a viewer.  Obviously nothing is going to happen. :-)

It would be good to implement the "public name" in the meta-server to be
descriptive instead of the reachable "reported hostname" (which should not =
be
removed).  Then the server can be called "Chatroom" or so.

> I'm willing to run such a game on my firewall computer, and register=20
> that game at the main meta-server.
> Players could first join this 'game', make arrangements about new=20
> games to be started, and then (re)connect to a real game that is=20
> hosted by one of the players.

Sounds good, at least as a temporary solution.

Thanks,
Bas

--=20
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

[Pio-temporary] Regarding GGZ (RFE #641445)

[Roland C. <rc...@us...>]

Hello all,

For a while I had been thinking about using GGZ for a chat room in the 
meta-server. GGZ offers functionality to join and leave games, start 
new games, add computer players, chat before a game starts, etc.

But I'm running Debian, and GGZ in Debian has for a long time been an 
old version, and recently it has been removed from the Debian 
repository.

So what should I do with that old feature request? Shall I close it, 
or is there another alternative that is worth looking into?

I have an alternative for a chat room in the meta-server:
If there is a .game with only one land tile, and a required number of 
players of more than two (or perhaps 99), that game can never really 
be started nor finished, and thus serve as a kind of chat room.
I'm willing to run such a game on my firewall computer, and register 
that game at the main meta-server.
Players could first join this 'game', make arrangements about new 
games to be started, and then (re)connect to a real game that is 
hosted by one of the players.

Regards,
Roland Clobus

Re: [Pio-temporary] Ideas for AI playing development cards

[Brian W. <bwe...@xb...>]

On Sat, 1 Oct 2005, Roland Clobus wrote:

> There was a bug in the AI that prompted me to look a little closer at
> the AI code.
>
> I think the AI could make better decisions when to play a development
> card. The AI is called greedy, so it should get as much resources and
> build as fast as it can, but I think it could delay some actions when
> it will have no direct benefit.

This sounds like a good idea.

>
> Year of Plenty:
> Current: will be played anytime the bank has at least 2 resources. If
> the bank does not contain anything the AI likes, it will request the
> resources for a road, and if the bank is too empty, it will just pick
> something at random.
>
> Proposed: the bank must have at least 2 resources. If the bank does
> not contain anyting the AI likes, determine whether it is possible to
> get enough resources to perform a maritime trade to get the resource
> the AI needs (in the next turn). If not, determine whether the AI is
> allowed to place a road [*1] and the resources are in the bank, and
> request that. If all fails: don't play this card yet.

I'm a bit confused by this logic.  If the bank doesn't contain any 
resources the AI wants, it doesn't matter whether the AI can get enugh 
resources to be able to perform a maritime trade next turn, since there's 
a good chance there still won't be any resources it wants, and it also 
means the AI is more likely to have over 7 cards.

I wonder if it would be possible to figure out if the AI is 1-2 cards 
short of a city/settlement/road it wants to build, and only play the card 
in that case.

> Monopoly:
> Current: will be played when the other players have at least six
> resources cards in total. If the AI doesn't need anything in
> particular, it will pick the resource that all players have the most
> of.
>
> Proposed:  will be played when the other players have at least six
> resources cards in total. If the AI doesn't need anything in
> particular, don't play it yet.

Agreed, although I wonder if the AI should take into account the number of 
cards.  For example, if the AI wants a lumber, and will only get 1 lumber 
by playing monopoly, but could get 10 brick, taking the brick would be a 
much better idea, since it could do a 4:1 (or better) trade and still come 
out way ahead.

I know I've played monopoly after a ton of cards of one type have been 
given out, just to use them for trading.

> Road building:
> Current: play whenever two or more road segments are left.
>
> Proposed: play whenever two or more road segments are left, but not
> when road segments are not allowed to be built [*1]

OK.

> Gold:
> Current: when the AI does want something, get it. Otherwise, start
> emptying the bank starting from the first resource.
>
> Proposed: when the AI does want something, get it. Otherwise, start
> emptying the bank starting from the resource that has the best
> maritime trade ratio.

Unlike the dev cards, gold can't be deferred until later, so there might 
be situations where the AI doesn't want anything because it can, for 
example, already build a settlement.  It might be worth it to figure out 
what the AI will do first, and if its first action is to buy something, 
re-evaluate what it would want after buying it, then choose that, falling 
back to something like your suggestion afterwards.  This might be too 
complicated, though, and your idea would still help.

Brian

[Pio-temporary] Ideas for AI playing development cards

[Roland C. <rc...@us...>]

Hello all,

There was a bug in the AI that prompted me to look a little closer at 
the AI code.

I think the AI could make better decisions when to play a development 
card. The AI is called greedy, so it should get as much resources and 
build as fast as it can, but I think it could delay some actions when 
it will have no direct benefit.

Year of Plenty:
Current: will be played anytime the bank has at least 2 resources. If 
the bank does not contain anything the AI likes, it will request the 
resources for a road, and if the bank is too empty, it will just pick 
something at random.

Proposed: the bank must have at least 2 resources. If the bank does 
not contain anyting the AI likes, determine whether it is possible to 
get enough resources to perform a maritime trade to get the resource 
the AI needs (in the next turn). If not, determine whether the AI is 
allowed to place a road [*1] and the resources are in the bank, and 
request that. If all fails: don't play this card yet.

Monopoly:
Current: will be played when the other players have at least six 
resources cards in total. If the AI doesn't need anything in 
particular, it will pick the resource that all players have the most 
of.

Proposed:  will be played when the other players have at least six 
resources cards in total. If the AI doesn't need anything in 
particular, don't play it yet.

Road building:
Current: play whenever two or more road segments are left.

Proposed: play whenever two or more road segments are left, but not 
when road segments are not allowed to be built [*1]

Gold:
Current: when the AI does want something, get it. Otherwise, start 
emptying the bank starting from the first resource.

Proposed: when the AI does want something, get it. Otherwise, start 
emptying the bank starting from the resource that has the best 
maritime trade ratio.

Regards,
Roland Clobus

[*1] Sometimes the AI is not allowed to build a road. Otherwise it 
would just build roads, and skip building settlements (which require 
also brick and wood)

Re: [Pio-temporary] Re: pioneers support for getaddrinfo on cygwin

[Scott O. <sco...@gm...>]

Roland Clobus wrote:

>On Monday 19 September 2005 02:16, you wrote:
>
>I'm replying also to the mailing-list, so more people can read it.
>For Cygwin there is limited network support. The client worked the 
>last time I checked (the server not yet).
>  
>
Good point, I hadn't realized that the client  was functioning correctly 
without the fix.  You may just want to leave the server code alone until 
some cygwin lib package is released with minimal rfc2553 support.  If 
someone wants a working cygwin based server, they could just ask for a 
little help...

When I was going through the last gnocatan source code prior to finding 
the latest version of pioneers, I only saw a few references to 
getaddrinfo, freeaddrinfo, and maybe one or two more. 

BTW - Thanks for creating the README.cygwin notes!  It saved me a bunch 
of time trying to build gtk+, etc. on my RH9 box after not finding any 
appropriate rpms.

Scott

>So I now have 3 options:
>* Use a quick fix, and mix licenses
>* Use Winsock directly
>* Use older IPv4 only functions
>  
>
It seems that the ideal option is always limited by know-how, and free 
time:)  Despite my distaste for win32 apis and #defs.

>I prefer the last option, or else as little as possible dependance on 
>Winsock, except of course when the code from openssh could be used 
>instead.
>
>Regards,
>Roland Clobus
>  
>

Re: [Pio-temporary] Re: pioneers support for getaddrinfo on cygwin

[Arjan S. <ar...@an...>]

Roland Clobus wrote:

>I'm replying also to the mailing-list, so more people can read it.
>For Cygwin there is limited network support. The client worked the 
>last time I checked (the server not yet).
>  
>
It was working over here, too.

>Two weeks ago I've received a patch that will enable Pioneers to run 
>natively on WindowsXP, but it contains many #ifdef G_OS_WIN32, and I 
>am working on reducing that amount. That patch also contains code to 
>use Winsock2.
>Half a year ago I was searching for the availability of getaddrinfo 
>and related functions on Cygwin, and found that the status was in an 
>early beta stage, and not available for every (Win98SE+) version of 
>Windows. I've not looked at the current status.
>I've looked at the license from openssh, and it looks like that if I 
>use parts of that code, I mix two licenses, and I'm not sure if that 
>is possible/wished. Last year Arjan Schrijver used code from 
>PostgreSQL that is also not GPL. Then there was some discussion too. 
>I don't know what to do with such mix. Can it be done, or better not?
>  
>
Well, mostly it's the best way not to mix licences. However, in this 
case, it's not that bad after all.
Both PostgreSQL and OpenSSH are released under the BSD license. That 
means everybody is completely free to do with the code whatever they 
want. You may redistribute it under another license, as long as the 
copyright notice is contained within the source code. That's all, 
actually. No need for mixed licenses and such, just keep the copyright.

>But, if the code used only IPv4 related function calls (at least not 
>getaddrinfo etc.) I hope the networking code would contain very few 
>platform specific #ifdefs, and still be usable in Cygwin, MinGW, 
>Linux, etc.
>
>So I now have 3 options:
>* Use a quick fix, and mix licenses
>* Use Winsock directly
>* Use older IPv4 only functions
>
>I prefer the last option, or else as little as possible dependance on 
>Winsock, except of course when the code from openssh could be used 
>instead.
>  
>
I guess if the first option can be done cleanly, that would be the best 
one. Mixing the licenses is not an issue, as I already pointed out. 
Otherwise, it would be safe (for now) to use IPv4-only functions, since 
IPv6 won't be used much for the next couple of years.
Personally, I'd prefer the second option, as long as there won't be an 
enormous amount of ifdefs in the code. IMHO, the code should be as 
portable as possible (perhaps someone could take a look at current 
support for g_io_channel's in the Windows-version of gtk/glib).
Using Winsock would probably the most stable thing to do, as long as the 
code stays clean. It allows the use of native functions (for both IPv4 
and IPv6), which (hopefully) imply stability. Possibly it also improves 
the future-readyness of the code.

But, these are just my ideas on the subject, which are not necessarily 
correct (apart from the license thing).

Regards,
Arjan Schrijver

Re: [Pio-temporary] Re: [ pio-Patches-1293678 ] Enable compiler warnings without debugging support

[Roland C. <rc...@us...>]

On Tuesday 20 September 2005 02:25, Brian Wellington wrote:
> On Tue, 20 Sep 2005, Roland Clobus wrote:
> 
> > If --enable-warnings=yes is used, it will result in the same 
situation
> > as the current, except that the warnings will not be enabled when 
the
> > compiler is not called gcc (perhaps not a good idea, since it can
> > also be e.g. gcc-3.3)
> 
> This could easily be worked around by checking for a --version 
option and 
> parsing the result if there is one.

Ok, but the check should not become too complicated, otherwise I would 
be maintaining a configure script instead of Pioneers :-)
 
> > --enable-warnings: for compiler warnings
> > --enable-debug: for -ggdb3 and -O
> > --enable-logging: for -DDEBUG
> > --enable-deprecation-checks -D*_DISABLE_DEPRECATED
> > --enable-developer-only
> 
> I'm not sure why we'd want to set -O if --enable-debug is specified; 
it 
> makes debugging harder.  I could actually see setting -O if 
> --enable-warnings is specified, since gcc stupidly only prints 
certain 
> types of warning if optimization is enabled.

You're right. -O is only added to enable some warning flags to work. 
It should go with the --enable-warnings.

> > developer-only would turn on all four.
> > ./configure --enable-developer-only --disable-logging should then 
be
> > able have all warnings and debug information, but without the
> > logging.
> 
> I like that idea.

I just realised that a commandline switch for developers only already 
exists: --enable-maintainer-mode. That macro is normally 
automatically set when calling with ./autogen.sh, but not with a 
normal ./configure.

Regards,
Roland Clobus

Re: [Pio-temporary] Re: [ pio-Patches-1293678 ] Enable compiler warnings without debugging support

[Brian W. <bwe...@xb...>]

On Tue, 20 Sep 2005, Roland Clobus wrote:

> If --enable-warnings=yes is used, it will result in the same situation
> as the current, except that the warnings will not be enabled when the
> compiler is not called gcc (perhaps not a good idea, since it can
> also be e.g. gcc-3.3)

This could easily be worked around by checking for a --version option and 
parsing the result if there is one.

> But I was experimenting with what would happen if I enabled nearly all
> compiler warnings, --enable-warnings=full. It turns out that a few
> useful additional warnings were given.
>
> I've looked in gnome-compiler-flags.m4 (part of the gnome-common
> package) for ideas.  It contains an AM_macro that enables compiler
> warnings, but they are less strict than the collection of warnings we
> currently use. It think we should at least keep the current list of
> warning checks.
>
> However, gnome-compiler-flags.m4 contains a nice for loop that will
> check the capability of gcc to use a certain -Wflag. Perhaps that can
> be used to determine the available gcc warning flags.

Sounds good.

> --enable-warnings: for compiler warnings
> --enable-debug: for -ggdb3 and -O
> --enable-logging: for -DDEBUG
> --enable-deprecation-checks -D*_DISABLE_DEPRECATED
> --enable-developer-only

I'm not sure why we'd want to set -O if --enable-debug is specified; it 
makes debugging harder.  I could actually see setting -O if 
--enable-warnings is specified, since gcc stupidly only prints certain 
types of warning if optimization is enabled.

> developer-only would turn on all four.
> ./configure --enable-developer-only --disable-logging should then be
> able have all warnings and debug information, but without the
> logging.

I like that idea.

> Using CFLAGS should work again.

Good.

>>>> I could try to come up with a patch to do this if there's
>>>> interest, but I'm not going to fight with autoconf unless
>>>> there's consensus.
>
> I've made many changes to the autoconf script already. It would not be
> hard for me to implement the mentioned changes.

OK.

>> Agreed.  Your patch is definitely an improvement over the current code,
>> and should be applied.  The we can figure out what the best way to move
>> forward from there.
>
> Agreed.
> But since I've put some time into this, and I might as well finish my
> patch, I would like to propose the following:
> In about 18 hours from now I can spend some time for Pioneers again.
> If I don't have a patch posted in 24 hours from now, let's apply the
> patch from Bas, otherwise look at the new patch.

I'm ok with this too.

Brian

[Pio-temporary] Re: pioneers support for getaddrinfo on cygwin

[Roland C. <rc...@bi...>]

On Monday 19 September 2005 02:16, you wrote:
> Hi Roland,
>=20
> I noticed that pioneers-0.9.23 and the latest build from CVS today=20
do=20
> not appear to support networking on cygwin.
>=20
> Here's a quick fix if you are interested:
>=20
> There is likely an easier way, but I just hacked it in by getting an=20
> ipml. of  getaddrinfo, etc.  from e.g.
> /usr/src/openssh-4.2p1-1/openbsd-compat/fake-rfc2553.c  (and then=20
> commenting in the appropriate HAVE_GETADDR* in config.h)

I'm replying also to the mailing-list, so more people can read it.
=46or Cygwin there is limited network support. The client worked the=20
last time I checked (the server not yet).

Two weeks ago I've received a patch that will enable Pioneers to run=20
natively on WindowsXP, but it contains many #ifdef G_OS_WIN32, and I=20
am working on reducing that amount. That patch also contains code to=20
use Winsock2.
Half a year ago I was searching for the availability of getaddrinfo=20
and related functions on Cygwin, and found that the status was in an=20
early beta stage, and not available for every (Win98SE+) version of=20
Windows. I've not looked at the current status.
I've looked at the license from openssh, and it looks like that if I=20
use parts of that code, I mix two licenses, and I'm not sure if that=20
is possible/wished. Last year Arjan Schrijver used code from=20
PostgreSQL that is also not GPL. Then there was some discussion too.=20
I don't know what to do with such mix. Can it be done, or better not?

But, if the code used only IPv4 related function calls (at least not=20
getaddrinfo etc.) I hope the networking code would contain very few=20
platform specific #ifdefs, and still be usable in Cygwin, MinGW,=20
Linux, etc.

So I now have 3 options:
* Use a quick fix, and mix licenses
* Use Winsock directly
* Use older IPv4 only functions

I prefer the last option, or else as little as possible dependance on=20
Winsock, except of course when the code from openssh could be used=20
instead.

Regards,
Roland Clobus

Re: [Pio-temporary] Re: [ pio-Patches-1293678 ] Enable compiler warnings without debugging support

[Roland C. <rc...@us...>]

On Monday 19 September 2005 18:20, Brian Wellington wrote:
> On Mon, 19 Sep 2005, Bas Wijnen wrote:
> 
> >>> Comment By: Brian Wellington (bwelling)
> >> Date: 2005-09-18 20:56
> >>
> >> Roland - I don't think your patch will work, because the
> >> specific warnings supported by gcc vary greatly by version
> >> (and since many distributors shipped patched gcc, even
> >> version checking isn't enough).
> >
> > Good point.  However, the warnings are not new: They are currently 
in
> > rules.make, and can be enabled with --enable-debug.  I would like 
to compile
> > with lots of warnings, but of course it shouldn't break the 
compilation.  Is
> > there a solution for this?
> 
> It looked like the attached patch added more warnings than were 
currently 
> in rules.make, but I could be wrong.

That is correct. I was reading the man page of gcc to see if there are 
more options that eventually could be added.

If --enable-warnings=yes is used, it will result in the same situation 
as the current, except that the warnings will not be enabled when the 
compiler is not called gcc (perhaps not a good idea, since it can 
also be e.g. gcc-3.3)

But I was experimenting with what would happen if I enabled nearly all 
compiler warnings, --enable-warnings=full. It turns out that a few 
useful additional warnings were given.

I've looked in gnome-compiler-flags.m4 (part of the gnome-common 
package) for ideas.  It contains an AM_macro that enables compiler 
warnings, but they are less strict than the collection of warnings we 
currently use. It think we should at least keep the current list of 
warning checks.

However, gnome-compiler-flags.m4 contains a nice for loop that will 
check the capability of gcc to use a certain -Wflag. Perhaps that can 
be used to determine the available gcc warning flags.

> >> I'm a bit confused as to the intent of the original patch -
> >> having debugging symbols in a binary doesn't really cause
> >> any burden other than increased disk usage.  Given that hard
> >> drives are effectively free (and a pioneers build with
> >> debugging symbols is still going to use way less space than,
> >> say, gnome) and debugging symbols are useful if there are
> >> bugs, I don't know why they should be split.
> >
> > The difference is more than a factor of 3 for the client (I didn't 
check the
> > others).  I don't think it is reasonable to ask people who aren't 
going to
> > submit bugs to install that.  At least for Debian they will be 
stripped
> > anyway, so that's no problem.  I don't know what other 
distributions do
> > though.
> 
> It might be a factor of 3, but on my system (FC4/x86), the total 
size of 
> the 6 installed binaries is only about 2.3M, and the total size of 
the 
> other installed files is about 1.4M (and wouldn't be affected by 
this).
> That said, I don't have any problem making this configurable.
> 
> > I have been building debugging versions of the debian packages, it 
might be a
> > good idea to put them on the web somewhere to ask people to use 
them if we
> > want more info.  Of course I can only build for my own 
architecture (although
> > I can provide a package which people can use to build it on their 
machine),
> > which is currently i386.
> 
> OK.
> 
> >> In my opinion, what should be split is the debug/warning
> >> code and the deprecation flags.
> >
> > Sounds good.
> >
> >> Splitting off -DDEBUG from warnings could also be useful,
> >> but I don't see any good reason why -DDEBUG and -g should be
> >> tied together - they're completely unrelated.
> >
> > The reason they're together (and called --enable-debug) is that 
you'll want
> > both when debugging.  I agree though that it makes sense to split 
them.
> 
> That's true, but I've also found cases where I've been trying to 
debug 
> something in gdb, and the huge amount of data printed when DEBUG is 
set 
> actually makes it harder to follow.
> 
> >> I'd suggest something like:
> >>   - --enable-gcc-warnings (-Wall, etc)
> >>   - --enable-debug (-DDEBUG)
> >>   - --enable-deprecation-checks (or
> >> --enable-glib-deprecation checks, etc)
> >>   - possibly a way to set all of these with one flag
> >
> > Sounds good.

--enable-warnings: for compiler warnings
--enable-debug: for -ggdb3 and -O
--enable-logging: for -DDEBUG
--enable-deprecation-checks -D*_DISABLE_DEPRECATED
--enable-developer-only

developer-only would turn on all four. 
./configure --enable-developer-only --disable-logging should then be 
able have all warnings and debug information, but without the 
logging.

> >>   - always build with -g unless CFLAGS is set, like most
> >> other autoconf-based software.
> >
> > I don't know about this.  Perhaps it makes sense that people who 
compile from
> > source have enough disk space anyway.  Distributions will strip 
the files
> > before installing (at least I know I will do that for Debian), so 
that should
> > be ok.
> 
> I'm not sure about debian, but a lot of RH/Fedora packages set 
CFLAGS 
> before invoking configure as part of the build process.  I know that 
> setting CFLAGS doesn't currently work for pioneers (or was that 
fixed? 
> I'm a bit behind), but that's a fairly common solution.

Using CFLAGS should work again.
 
> >> I could try to come up with a patch to do this if there's
> >> interest, but I'm not going to fight with autoconf unless
> >> there's consensus.

I've made many changes to the autoconf script already. It would not be 
hard for me to implement the mentioned changes.

> > In cases like these, I think it is a good idea to apply a patch 
which makes
> > the thing work, and move the report to the feature requests.  
While my patch
> > may not be the final solution, it does fix a problem (it's even 
more relevant
> > for the AI-empty-bank-maritime-trade bug).  How about the default 
policy of
> > fixing the bug first, and changing the thing later after we 
decided what's the
> > Right Thing(tm) to do in that situation.  In particular for bugs, 
it's not
> > acceptable to leave them open just because we don't know how we 
want to
> > restructure the code, IMO.
> 
> Agreed.  Your patch is definitely an improvement over the current 
code, 
> and should be applied.  The we can figure out what the best way to 
move 
> forward from there.

Agreed.
But since I've put some time into this, and I might as well finish my 
patch, I would like to propose the following:
In about 18 hours from now I can spend some time for Pioneers again. 
If I don't have a patch posted in 24 hours from now, let's apply the 
patch from Bas, otherwise look at the new patch.

Regards,
Roland

Re: [Pio-temporary] Re: [ pio-Patches-1293678 ] Enable compiler warnings without debugging support

[Brian W. <bwe...@xb...>]

On Mon, 19 Sep 2005, Bas Wijnen wrote:

>>> Comment By: Brian Wellington (bwelling)
>> Date: 2005-09-18 20:56
>>
>> Roland - I don't think your patch will work, because the
>> specific warnings supported by gcc vary greatly by version
>> (and since many distributors shipped patched gcc, even
>> version checking isn't enough).
>
> Good point.  However, the warnings are not new: They are currently in
> rules.make, and can be enabled with --enable-debug.  I would like to compile
> with lots of warnings, but of course it shouldn't break the compilation.  Is
> there a solution for this?

It looked like the attached patch added more warnings than were currently 
in rules.make, but I could be wrong.

The solution we use in our build system at work is to attempt to determine 
the version of gcc, and conditionally enable warnings when appropriate. 
This works for us, but we also have a much more limited number of gcc 
versions.

It's basically:
  - always add: -W -Wall -Wcast-qual -Wwrite-strings -Wpointer-arith
  - unless building C++, add: -Wmissing-prototypes
  - if gcc >= 3.2, add: -Wno-format-y2k -Werror
  - if gcc >= 3.4 and not building C++, add: -Wdeclaration-after-statement


>> I'm a bit confused as to the intent of the original patch -
>> having debugging symbols in a binary doesn't really cause
>> any burden other than increased disk usage.  Given that hard
>> drives are effectively free (and a pioneers build with
>> debugging symbols is still going to use way less space than,
>> say, gnome) and debugging symbols are useful if there are
>> bugs, I don't know why they should be split.
>
> The difference is more than a factor of 3 for the client (I didn't check the
> others).  I don't think it is reasonable to ask people who aren't going to
> submit bugs to install that.  At least for Debian they will be stripped
> anyway, so that's no problem.  I don't know what other distributions do
> though.

It might be a factor of 3, but on my system (FC4/x86), the total size of 
the 6 installed binaries is only about 2.3M, and the total size of the 
other installed files is about 1.4M (and wouldn't be affected by this).
That said, I don't have any problem making this configurable.

> I have been building debugging versions of the debian packages, it might be a
> good idea to put them on the web somewhere to ask people to use them if we
> want more info.  Of course I can only build for my own architecture (although
> I can provide a package which people can use to build it on their machine),
> which is currently i386.

OK.

>> In my opinion, what should be split is the debug/warning
>> code and the deprecation flags.
>
> Sounds good.
>
>> Splitting off -DDEBUG from warnings could also be useful,
>> but I don't see any good reason why -DDEBUG and -g should be
>> tied together - they're completely unrelated.
>
> The reason they're together (and called --enable-debug) is that you'll want
> both when debugging.  I agree though that it makes sense to split them.

That's true, but I've also found cases where I've been trying to debug 
something in gdb, and the huge amount of data printed when DEBUG is set 
actually makes it harder to follow.

>> I'd suggest something like:
>>   - --enable-gcc-warnings (-Wall, etc)
>>   - --enable-debug (-DDEBUG)
>>   - --enable-deprecation-checks (or
>> --enable-glib-deprecation checks, etc)
>>   - possibly a way to set all of these with one flag
>
> Sounds good.
>
>>   - always build with -g unless CFLAGS is set, like most
>> other autoconf-based software.
>
> I don't know about this.  Perhaps it makes sense that people who compile from
> source have enough disk space anyway.  Distributions will strip the files
> before installing (at least I know I will do that for Debian), so that should
> be ok.

I'm not sure about debian, but a lot of RH/Fedora packages set CFLAGS 
before invoking configure as part of the build process.  I know that 
setting CFLAGS doesn't currently work for pioneers (or was that fixed? 
I'm a bit behind), but that's a fairly common solution.

>> I could try to come up with a patch to do this if there's
>> interest, but I'm not going to fight with autoconf unless
>> there's consensus.
>
> In cases like these, I think it is a good idea to apply a patch which makes
> the thing work, and move the report to the feature requests.  While my patch
> may not be the final solution, it does fix a problem (it's even more relevant
> for the AI-empty-bank-maritime-trade bug).  How about the default policy of
> fixing the bug first, and changing the thing later after we decided what's the
> Right Thing(tm) to do in that situation.  In particular for bugs, it's not
> acceptable to leave them open just because we don't know how we want to
> restructure the code, IMO.

Agreed.  Your patch is definitely an improvement over the current code, 
and should be applied.  The we can figure out what the best way to move 
forward from there.

Brian

[Pio-temporary] Re: [ pio-Patches-1293678 ] Enable compiler warnings without debugging support

[Bas W. <sh...@fm...>]

> >Comment By: Brian Wellington (bwelling)
> Date: 2005-09-18 20:56
>=20
> Roland - I don't think your patch will work, because the
> specific warnings supported by gcc vary greatly by version
> (and since many distributors shipped patched gcc, even
> version checking isn't enough).

Good point.  However, the warnings are not new: They are currently in
rules.make, and can be enabled with --enable-debug.  I would like to compile
with lots of warnings, but of course it shouldn't break the compilation.  Is
there a solution for this?

> I'm a bit confused as to the intent of the original patch -
> having debugging symbols in a binary doesn't really cause
> any burden other than increased disk usage.  Given that hard
> drives are effectively free (and a pioneers build with
> debugging symbols is still going to use way less space than,
> say, gnome) and debugging symbols are useful if there are
> bugs, I don't know why they should be split.

The difference is more than a factor of 3 for the client (I didn't check the
others).  I don't think it is reasonable to ask people who aren't going to
submit bugs to install that.  At least for Debian they will be stripped
anyway, so that's no problem.  I don't know what other distributions do
though.

I have been building debugging versions of the debian packages, it might be=
 a
good idea to put them on the web somewhere to ask people to use them if we
want more info.  Of course I can only build for my own architecture (althou=
gh
I can provide a package which people can use to build it on their machine),
which is currently i386.

> In my opinion, what should be split is the debug/warning
> code and the deprecation flags.

Sounds good.

> Splitting off -DDEBUG from warnings could also be useful,
> but I don't see any good reason why -DDEBUG and -g should be
> tied together - they're completely unrelated.

The reason they're together (and called --enable-debug) is that you'll want
both when debugging.  I agree though that it makes sense to split them.

> I'd suggest something like:
>   - --enable-gcc-warnings (-Wall, etc)
>   - --enable-debug (-DDEBUG)
>   - --enable-deprecation-checks (or
> --enable-glib-deprecation checks, etc)
>   - possibly a way to set all of these with one flag

Sounds good.

>   - always build with -g unless CFLAGS is set, like most
> other autoconf-based software.

I don't know about this.  Perhaps it makes sense that people who compile fr=
om
source have enough disk space anyway.  Distributions will strip the files
before installing (at least I know I will do that for Debian), so that shou=
ld
be ok.

> I could try to come up with a patch to do this if there's
> interest, but I'm not going to fight with autoconf unless
> there's consensus.

In cases like these, I think it is a good idea to apply a patch which makes
the thing work, and move the report to the feature requests.  While my patch
may not be the final solution, it does fix a problem (it's even more releva=
nt
for the AI-empty-bank-maritime-trade bug).  How about the default policy of
fixing the bug first, and changing the thing later after we decided what's =
the
Right Thing(tm) to do in that situation.  In particular for bugs, it's not
acceptable to leave them open just because we don't know how we want to
restructure the code, IMO.

Thanks,
Bas

--=20
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Re: [Pio-temporary] Turn on compiler warnings

[Bas W. <sh...@fm...>]

On Sat, Sep 17, 2005 at 03:31:56PM +0200, Bas Wijnen wrote:
> However, if you prefer to see this as a flag, and you want to define it i=
n an
> debug.m4 file which is used in configure.ac and then referenced in Makefi=
le.am
> to be used, I don't mind.  An other option is to add them to the compiler
> definition.  That is something which should be done in configure.ac.  But=
 in
> any case, if using a separate .m4 file, it should IMO only define flags in
> there, they should be used elsewhere.

Oh, and see I forgot to explicitly say: AM_* should be owned by automake, a=
nd
no other program should touch it.  That includes autoconf.  Well, at least
that's what I think about it. :-)

Thanks,
Bas

--=20
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Re: [Pio-temporary] Turn on compiler warnings

[Bas W. <sh...@fm...>]

On Sat, Sep 17, 2005 at 03:05:25PM +0200, Roland Clobus wrote:
> Hello all,
>=20
> I've decided to move the discussion from the tracker to the mailing=20
> list. Previous discussion in the tracker (Patches item #1293678):

Good idea.

> Ever since rules.make was introduced, it was a hack because it would=20
> allow us to do things that we could not do with the autoconf tools.
> I would like to see that file removed eventually.

I agree with that.  However, recently I noticed that automake supports
non-recursive Makefiles as well (that is, one Makefile in the toplevel
directory which has all the rules and doesn't call make for subdirectories).

There are several reasons that this is a good thing.  See
http://www.gnu.org/software/automake/manual/html_node/Alternative.html
and the article linked from there.

Now if we would go for this approach, we would of course no longer need
rules.make.

> For now, the discussion focusses on the debug_includes part.
>=20
> Bas wrote a patch that would merge the warnings settings and the debug=20
> settings to the variable extra_includes, by modifying rules.make

Right.  While I agree that it should eventually be removed somehow (I'd pre=
fer
generating one Makefile from a Makefile.am which includes Makefile.am's from
other subdirectories to keep things readable), this patch does not attempt =
to
make a start with that.

> I prefer to use the configure.ac way because that will allow fine=20
> grained control over the arguments to gcc. It will also disable the=20
> commandline arguments that enable the compiler warnings when another=20
> compiler than gcc is found.

I assume can also be done with only a test in configure.ac, and the
implementation in Makefile.am.

> Bas, you wrote:
> <quote>
> I think the strings
> which end up in the final Makefile should be defined in
> Makefile.am (or in /usr/share/aclocal/*.m4 as a variable
> definition to be referenced in Makefile.am).
> </quote>
>=20
> I'm not sure what do you mean by that.

I see configure.ac as a place to test for things and to copy things into the
Makefile, not to actually generate content (for the Makefile).  That content
should be in Makefile.in, substituted with flags definitions (which are in
/usr/share/aclocal).

> I see configure.ac as a customized version of /usr/share/aclocal/*.m4.=20

I don't, I see it as the manager to use the information in there and merge =
it
with the local things which are in Makefile.am.

> If the text to turn the warnings on is too long, I could separate it=20
> to a *.m4 file, but the effect would be the same.

The effect is the same when we do it via rules.make as well. ;-)

However, if you prefer to see this as a flag, and you want to define it in =
an
debug.m4 file which is used in configure.ac and then referenced in Makefile=
=2Eam
to be used, I don't mind.  An other option is to add them to the compiler
definition.  That is something which should be done in configure.ac.  But in
any case, if using a separate .m4 file, it should IMO only define flags in
there, they should be used elsewhere.

I hope this explains better how I see it.

Thanks,
Bas

--=20
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

[Pio-temporary] Turn on compiler warnings

[Roland C. <rc...@us...>]

Hello all,

I've decided to move the discussion from the tracker to the mailing=20
list. Previous discussion in the tracker (Patches item #1293678):
=2D--
Submitted By: Bas Wijnen (shevek)

Sometimes it's nice to see all the compiler warnings,
but it's not =A0a good idea to add any debugging symbols
to the executable. =A0I'm particularly thinking of
automated builds on the Debian build servers. =A0Seeing
warnings from other architectures would be nice, but we
don't want to put the burden of debugging symbols on
all Debian users.

So a little more fine grained control is needed.

This patch does that. =A0Note that "always enable
warnings when debugging" in configure.ac is really
about what happens in rules.make (debug_includes =3D
$(warnings_includes) ...). =A0The line in configure.ac is
just for telling the user about the situation.
=2D--
Comment By: Roland Clobus (rclobus)
I was also working on this, but I chose a different route.
I've adapted configure.ac to add the compiler warnings.

See the adapted patch. (It is work in progress, I need to
refine it some more)
=2D--
Comment By: Bas Wijnen (shevek)
Hmm, I think I like my approach better.  I think the strings
which end up in the final Makefile should be defined in
Makefile.am (or in /usr/share/aclocal/*.m4 as a variable
definition to be referenced in Makefile.am).

It would be a good idea to get rid of extra_includes
completely, and just push the things in AM_CPPFLAGS.=20
However, we should first agree on how to implement these
things. :-)
=2D---

New comments:
Ever since rules.make was introduced, it was a hack because it would=20
allow us to do things that we could not do with the autoconf tools.
I would like to see that file removed eventually.

=46or now, the discussion focusses on the debug_includes part.

Bas wrote a patch that would merge the warnings settings and the debug=20
settings to the variable extra_includes, by modifying rules.make

I was working on a patch (not completed) that would do something=20
similar, but controlled completely from within configure.ac

The final result would be similar:
=2E/configure --enable-warnings will turn on the compiler warnings
=2E/configure --enable-debug will turn on debug settings (+warnings)

I prefer to use the configure.ac way because that will allow fine=20
grained control over the arguments to gcc. It will also disable the=20
commandline arguments that enable the compiler warnings when another=20
compiler than gcc is found.

Bas, you wrote:
<quote>
I think the strings
which end up in the final Makefile should be defined in
Makefile.am (or in /usr/share/aclocal/*.m4 as a variable
definition to be referenced in Makefile.am).
</quote>

I'm not sure what do you mean by that.
I see configure.ac as a customized version of /usr/share/aclocal/*.m4.=20
If the text to turn the warnings on is too long, I could separate it=20
to a *.m4 file, but the effect would be the same.

Regards,
Roland Clobus