On Sat, Dec 03, 2005 at 01:36:15AM +0100, Hansenet Mail wrote: > I wholeheartedly agree with this. Communication is really important > in order to avoid messing up the code. But i think something even > more important is having a "big picture" of what the code and its > dependencies should look like. There is some general ideas > (including a proposal of me on the forum in "Coders Corner" some > time ago), but nothing that everybody really commited to.
> Having no "big picture" introduces another problem: Nobody can > really tell what architecture is supposed to look like and where > functionality is best put into. I asked that a couple of times and > there is some hint now and then but the general tendency is more > like "Go ahead and get it in, then we see if it works out well". I have tried to formalize my ideas in the wesnoth project definition (see graphincludes/project/wesnoth.pm in the wesnoth tree). Note that 1. the graph-includes API is quite dirty at this time 2. graph-includes itself is not currently able to render all the groups at this time either Both issues (as well as the low quality of the current graph-includes code, and win32 portability) are things I shall be working on (but would gladly accept help ;) > So what can we do about this? > 1. > I would really really love to have that "big picture". But that > - needs a lot of discussion in advance > - needs careful planing afterwards > - needs a strategy how to get from the current mess into an organized state > again > - has to be made known to and commited by everybody that touches src I think we can do that incrementally. Indeed the deps graph usually only make obvious a couple of issues, and other ones are made visible once the 1st round gets fixed. > 2. > I really really would love to see that dependency graph. Since i am > on windows, chances are bad at the moment, but maybe a graphics file > (gif?) every now and then would be very helpful. I have updated the graph at http://ydirson.free.fr/soft/wesnoth/graphs/ and put a PNG version at the same time. Beware, the current one is a 9247x2092 image. > If there is any chance to get that in the wiki i strongly second > doing that. The problem is that that graph gets easily outdated - I'd rather make it so everyone can regenerate the graph to see the effect of what he's about to commit. > 4. As i said earlier, better organizing the code turns out to be a > necessity IMHO. I go one step further and say: In a not too far > away future, if we don't get the code organized better, many changes > will break more things than they fix. This will become worse over > time. So i make a proposal here: Every patch, that changes > essential parts of the code, has to be sent to yann first to be > approved. This of course only under the preassumption that yann > finds enough time to not delay the development substantially. But i > don't think, that those kind of patches will appear very often. As a > first approach, we can define essential as changing includes of a > source file. Uh, I would not have the necessary bandwidth to held such a position :) I would prefer that we agree about what the file classification would be, and set this in graphincludes/project/wesnoth.pm as a reference. > >At the same time I noted a couple of other changes which I do not think > >are necessary, and indeed only break the consistency: > > > >+++ src/widgets/button.cpp (revision 8785) > >[...] > > #include "button.hpp" > >-#include "../font.hpp" > >+#include "font.hpp" > > #include "../image.hpp" > > #include "../log.hpp" > > > >That is, if this change was necessary on some platform, I'd rather > >have a look at why this change was necessary - and, also I'd like to > >encourage everyone not already doing that, to carefully review the > >"svn diff" before committing, to spot such things, which are much more > >apparent in the diff than in the plain files. > > If i understand this right, i just adapted the path to > font.hpp. Shouldn't break anything or make things more complicated. Right, but it seems customary in the source to use "../" to refer to src/*.hpp, and not have any prefix for the files in the same directory. This change, although it does not hurt because of the wide set of -I flags, can imply to the reader that font.hpp is in the same dir as button.hpp, instead of being near to image.hpp. > Btw, there is still an open issue about relative vs absolute paths > for header files. Most of them are absolute (originating from > src-directory), but there are some exceptions, mainly within the gui > widget files. We should have a decision about it and then clean up > the paths accordingly. Right, and I'd think we should settle on a minimal set of -I flags as well, to support that (upcoming) decision. > Ah, enough talking. Now it's your turn to comment on that. I am glad i don't > have to do all these decisions :P. > I am still experiencing "whelp protection", you know ;-) Eh eh :) Best regards, -- Yann Dirson <[EMAIL PROTECTED]> | Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux: | Freedom, Power, Stability, Gratis http://ydirson.free.fr/ | Check <http://www.debian.org/>
