xboard-devel
[Top][All Lists]
Advanced

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

Re: [XBoard-devel] Hi from a new member of the xboard team


From: Byrial Jensen
Subject: Re: [XBoard-devel] Hi from a new member of the xboard team
Date: Mon, 19 Dec 2011 23:52:00 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15

Den 19-12-2011 19:23, address@hidden wrote:

Hi

We always bring XBoard to a state where we can do a 'make' without getting
any warnings. When Arun encounters issues on the build server that do not
crop up when I compiled in my own Ubuntu 10.04, he reports them to me, and
we fix them too.

I develop on a 32-bit laptop, though, and XBoard was originally developed
on x86, so it contained many issues with pointer-int conversions when
compiled for 64-bit, and initially I created new issues of that type
because I was not sufficiently 64-bit aware. (Originally I only worked on
WinBoard, and virtually no WinBoard user compiles his own binary, so as
long as it compiled on my 32-bit system and I released the resulting
binary, there never were any complaints.)

As to warnings that occur when you do more strict checking than the
Makefile does, I can only say that some normally requested by -Wall where
intentionally disabled, because I considered them counter-productive. I am
not going to write error-prone and difficult to understand code just
because to silence some stupid, pedantic compiler... Silencing them with a
compiler option does the job quite effectively!

Well, the compiler only does what you tell it to do, and all kind of warnings can turned on and off individually (at least so with gcc which I use). I just wonder which warnings you consider to inflict error-prone and difficult to understand code. From my point of view they tend to do the opposite (that is make the code less error-prone and/or easier to understand), which is indeed the purpose of the warnings in my view.

That being said, the X-toolkit really invites sloppy programming by having
many parameters in the defined functions that are not used for anything,
or are used for something different than their declared type. I noticed

Agreed.

also that the header situation in XBoard is quite poor: many variables
shared between files are not declared in a header file, but just multiply
declared in the files that use them (sometimes as different types!).

I noticed so, too.

It would be good to clean up the code base in this respect. But it is
indeed a concern in which branch to do this, which needs careful
consideration. The branch that is currently developed the furthest is the
'aliennew' branch in my hgm.nubati.net repository. It forks off from
master, but unfortunately master has already evolved since the fork to a
point where it is no longer trivial to rebase aliennew to the head of
master, although it is in principle my intention to keep it there. I am
also not sure if aliennew is fully operational as XBoard compile; I only
used it to release the 'WinBoard Alien Edition'.

It would nice to have a roadmap for the development of xboard.

Which features should go into 4.6.0, and which into later versions? Where do this aliennew branch at hgm.nubati.net fit in for this?

If we already have everything new for 4.6.0, then it would be time to concentrate on bugfixing so it can be ready for release.

Best regards
- Byrial




reply via email to

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