[On in reply to any one message in particular, so not quoting anyone.] Probably the best way to do this is to provide a drop-in replacement for make w/ an optional patch to emerge/ebuild. Make is really what decides how many files will need to be compiled. (For many projects.)
Now that's not easy, but it'd probably be easier than asking the gmake and gcc teams to call back into your daemon and/or making and maintaining your own patches to these (and other) projects and having users recompile them to support your stuff. Along the way, you'd might be able to make recursive make's -j<jobs> option work a bit better. Overview: 1. Connect to daemon (if you can't just do your job and don't worry about progress reporting) 2. Report your pid; daemon uses this to build progress montior heirarchy. 3. Determine how many sub-jobs you have [ant, nant, make, scons, etc. already do something like this while they are building the dependency tree]; report to daemon. 4. Spawn jobs (squentially, in threads, as separate processes, whatever); if they are aware of the daemon they will be able to communicate with it independently. 5. As jobs finish; report to daemon. * Daemon should be light weight, and separate from the UI. * UI could provide different looks: - Progress bar tree (similar to a process tree) - Progress bar stack (for purely/mostly sequential tasks) - Nested progress bars (they'd fill up like eDonkey or GetRight's progress bars; not strictly reading order) * Programs that report to the deamon could also act like UI agents; in the case of make it could show a progress bar that's really the "sum" progress of it and all it's child makes. -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
