On Tuesday 01 February 2005 16:03, Boyd Stephen Smith Jr. wrote: > [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. Probably, but in the shorter term, a patch would be more likely, as rewriting make, making it bug-compatible, would be a project all its own.
> Make is really what decides > how many files will need to be compiled. (For many projects.) I know that. > 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. A patch to GCC isn't strictly neccessary, though. A wrapper could be created to run gcc, or it could be done by make just the same as for other processes that aren't progress-aware. I just thought that if it was patched, it could tell what stage of compilation it was on (preprocessing, compiling, assembling, etc.). Also, How often does make actually have any major architectural changes? I don't think a patch to make would be all that hard to maintain. > 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. Umm, yeah.That was exactly my idea. The UI would be a completely separate component, related only by a common communication protocol. Same with the clients. The daemon just keeps track. > * 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) Of course. The author of a viewer could make the progress bars any way they want. As an example, I might even write a web-based viewer. > * 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. Maybe. This would be, in some ways, harder. I would go more for just supressing console output and forking to the background Also, here's an expansion of my concept: a client, bundled in the distribution, to allow shell scripts (ebuilds, anyone?) to use the system. Here's how I see it working: Two parts: 1) a *client* daemon. This would be the process that actually communicates with the master daemon. It would keep the connection to the master open, and would also have a consistent PID (unlike a shell script, which, AFAIK, may not). We don't want the master daemon to think we mysteriously died and report an error. This client daemon would keep track of just the one job's tasks. 2)the API. I see this as two parts as well: A binary to do the actual communication, and a shell script function library, so that it can change environment variables -- t3h 3l3ctr0n3rd <[EMAIL PROTECTED]> Supermarket Deli Clerk and Student Programmer
pgpDqup6enPgU.pgp
Description: PGP signature
