Alec Warner wrote:
I have emerge rewritten ( somewhere ) for HEAD once all of Brian's
config/domain/crazy stuff goes in, unless someone wants to unlease
modular emerge now, in which case I can pull the code out of the cobwebs
of my ${HOME} and work on it again.
Basically the code allowed you to have a folder for modules that emerge
would detect at run-time, and load the proper ones depending on user
specification. The bonus to this was that some tools would be merged
into emerge instead of being seperate, which many users got upset about.
"emerge --rebuild" = revdep-rebuild -X for example. The main problem
with this is basically the same as above; emerge serves about 12
different functions with crappy code everywhere, I managed to replicate
about half the functionality by just copying and pasting important code
everywhere, but most of it still needs to be completely rewritten (
*stabs depgraph* ). I was going to wait for the new API to be done ( no
use rewriting emerge twice, IMHO ), but if you want it done now it
wouldn't be a big deal.
Hmm, interesting. I can see how building other tools into the emerge interface
would be useful if it allows more code to be shared somehow (and less
duplication). Are there other reasons for combining other tools into the same
interface?
My main concern about "rewritten" code is that, depending on the nature of the
code being rewritten, it may be likely to introduce unwanted changes or regressions. Of
course, thats why I put so much emphasis on careful refactoring/reorganizing of existing
code that is known to work in the desired way.
I don't see a reason to keep messy code around for long periods of time when it
can be so quickly reorganized. Why wait? Messy code only makes more difficult
the job of maintaining and improving the code.
Zac
--
[email protected] mailing list
