On Fri, Dec 02, 2005 at 08:32:56PM -0500, John McNabb wrote:
> It would, however, be reasonable to identify the "low-level" source
> files that should be kept to as slim an include list as possible.
> Modifications to the include list on these files then could require
> approval by one individual. I think that this has a reasonable
> chance of success. Yann would be the obvious person to take this
> task on if he was willing. Yann, any comments?
See my comment in previous mail: it would be imho more adequate to
define several groups, and be only restrictive about which kind of
inter-group dependencies we allow.
Most of it could even make this automatically tested at build time, by
making each group a shared lib, and linking that shared lib against
the dependant groups. Then a simple "ldd -r" test on the shared lib
would bomb out if any library dependency is lacking. This would not
catch any header-level dependency without binary counterpart
(eg. typedefs), but those would be shown in the graph anyway, and they
shall not be the toughest to tame anyway.
> I certainly do think that moving the wesnoth codebase towards a more
> maintainable structure is a good thing. I do not, however, think that major
> refactoring of the code should be done purely for refactoring's sake. When
> the
> opportunity arises because of other changes, then reorganing the structure
> should be done. Basically, I think that a complete overhaul is doomed to
> failure because of the scope of the code changes needed. Someone that has
> that
> much interest, ability, and time is probably going to just write their own
> game from scratch.
I do not think any project-size refactoring is needed now. The code
is quite well structured and modularized already, only a couple of
well-idenfied (or easily identifiable) things cause annoying
dependencies.
Next on my list as of Nov 9th (ie. after splitting preferences_display
out of preferences) are:
- help strings in video.* cause a loop : we should imho split the
stuff using them out, to make "video" part of the low-level graphics
core.
- similarly font.* use floating labels and tooltips stuff
I had delayed working on this because of the intersection with Ayin's
video rework - as a sidenote, I'm still in favor of seeing his work
enter the svn ASAP, or it may well end up being just lost work...
> > If i understand this right, i just adapted the path to font.hpp. Shouldn't
> > break anything or make things
> > more complicated. 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.
>
> I agree, but I have no particular preference myself. Before making a
> decision
> on the matter, does anyone have any strong opionions one way or the other?
Requiring to use the topdir-based paths everywhere may be a good
thing, but is hard to enforce right now, because of the implicit
"-I.", which causes several paths to be valid to reach each header.
This could be enforced by moving the headers into an include dir, but
since we have at least 3 ways of building the files (autostuff on
unices, xcode on macosx, ms-whatever on win32).
I don't count the kdevelop file which has not changed since 18 months,
and is probably useless by now. Anyone using it ? Should we remove
it to avoid luring people into attempting to use it ?
This also raises again the idea of switching to a single build system
for all platforms. I already mentionned the possibility to switch to
jam, but at that time silene mentionned that Boost, for one, was
consirering switching from (their own modified version of) jam to
scons. I have only limited experience of scons - can anyone comment
on this tool ? From what I've seen, I fear that its tight integration
into python, while surely being quite powerful, may be a problem (just
like perl's excessive flexibility is a problem for some people).
Since I do not think we're likely to be limited by the expressive
power of jam in the near future, it would tend to be my candidate of
choice. But I'd like to hear from others, since it is obviously not
the only modern cross-platform build tool out there.
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/>
