Yukiko wrote:Just try to trace through any package in any Distro version
That's an unfortunate truth here. Believe it or not, the knowledge of that fact has tempered my response to this suggestion :razz: Because I know that by default, everyone's includes were a mess.
However, I don't recall the 095 distro having much trouble with large numbers of unneeded includes, thereby causing unnecessary recompiles. As you noted above somewhere, too; So what? It seems like you would have to have some really broad problem here for it to be noticeable; A half-dozen scripts with an extraneous include would hardly be something to notice, unless there is, otherwise, only a like or smaller number of scripts that legitimately need it. In such a case, it would seem easy to fix the problem.
But even if you are starting out with the 'fresh' distro, you still should not be just tossing include statements into your scripts as a way to 'fix' them... yet I know from looking at others' code, and seeing how many include lines exist, then are commented out (often to be later added in below), I know that people seem to do this, an awful lot.
To the extent that your includes simply are a mess, and that's simply what you must do to work; OK. I worked with a distro in the past, and I originally started with a script set that, as full of neat ideas it may have been, was a horrible mess as far as includes and lots of other basic scripting problems (WoD/Ackadia); So I had to deal with all of this myself.
It took time - lots of it - to get the includes into something resembling organization. In fact, I would say that only my recent upgrade work - where I also brought in another scripter - forced me to really finish that. Up until recently, I still had, for example, std.inc. Forgive me, those who wrote functions in it - but at least the version of it I had was a horrible mess; mostly filled with functions that had been replaced with core functions since 092, at least. However, the biggest problem with it was that it was a huge hodgepodge of functions, very few of which were related to any other functions there. I had, over the years, been removing any links into that file from any of my scripts; replacing them with calls to core functions that did the same thing, or creating new, targeted includes that made more sense (so that when you see the name of an include, you know exactly what it's for. Exactly what obvious purpose does an include named "std" serve? Compare that to an include named "webbrowser" or "townstones" or "magiceffects". Granted, often the 'obvious' is a bit esoteric, but still...)
It was only when I brought on someone to help, and they started using functions again in std.inc, that I realized that file was still there, and needed to be deleted. Having another set of eyes and hands in the scripting made me realize even more how important it was to keep things organized and understandable. I still have some way to go with that now, due to having more hands in the soup - for instance, I had long relied on 'clips' in TextPad as a reference to what functions I had available where, and what their parameter lists were, when I did not remember something off the top of my head (which, I almost never do!)... but of course, my scripter does not use TextPad, so I can't just send him my clip file. This has left me largely manually documenting the functions in my includes for his use.
It would have been much better had I done something like have a comment 'header' in each include which included a list of the functions meant to be called from outside that include, along with their return values and explanations of their parameters. As it is, he's done a good job of discovering the uses of the include functions themselves (often he goes there before he goes to the Core functions, which is how he ended up using functions in std.inc, most of which had better Core functions instead)
So.. umm... that's my big rant for the day! :razz:
ops: 
:mad: :? :shock: :sad: 