On Thu, 2008-02-07 at 16:48 -0800, Newell Jensen wrote: > > > I've volunteered to act as a mentor this year, and if you > ended up > working on any xgsch2pcb code (or were to take parts of it to > use in a > more general work-flow tool), then I would indeed be > interested to work > with you on this project. > > > So would you be the main "overseer" for the Project Manager or only if > it dealt in some way with xgsch2pcb?
This would be decided amongst the gEDA developers, it is likely that more than one person would be interested and involved in any projects. > Who would be the main design architect for this and has anyone come > up with a design for how they want the work flow to be abstracted? This would depend to a certain extent on the student, and what they wanted out of the project. Peter Brett did come up with a concept for this already, but we implemented xgsch2pcb instead of getting bogged down in a big framework. It was / is intended that portions of the code can be re-used as one "edge" in a directed graph representing this particular work-flow. I think you'll get more out of the project the more fun you have with it, so if you want to do the design work with us, that is all the better. I don't expect spending the summer coding up some prescribed design would be much fun. > If not, was the student supposed to come up with this? I am willing > to start looking at the source of the different projects and seeing > how to interface them but if someone has already done a lot of the > brain work on this already and /or there is a set preference among the > gEDA user base to have it a certain way, that would be useful > information. I've you've been on the gEDA lists for any length of time, you'll realise that the gEDA developers and users will all have different ideas on almost any topic ;) > The first main step is to figure out a design that would be worth > while with most of the kinks thought out. Since this was already a > proposed project for GSoC 2007 has this part been worked on by anyone? It hasn't been worked on by anyone, further than the preliminary work Peter Brett and I did at CUED two summers ago before when we started xgsch2pcb. For me, I'd start looking at how a workflow can be expressed as a directed graph of dependencies. IE.. "make / cmake", only we'd probably want to code it internally to the project manager. If we assume automatic / manual updates are noticed by the project manager, not forwarded by the individual tools themselves, then the project manager will have to watch for changes to the various dependencies, and figure out which targets or deliverables need to be rebuilt, either automatically, semi-automatically (user triggered) or manually by user intervention (e.g. fixing a PCB layout to match a changed schematic). xgsch2pcb does this (not to cleverly) by looking at file timestamps when the user enters the window. A more complete solution would use a file monitoring API when available, such as inotify. I'd like to see some generic mechanism for adding "integrated" modules to perform some of these graph-edge steps. One example is the PCB manager class in xgsch2pcb which can feed changes from a schematic into a .pcb file. This could be anything from a config file allowing you to give a line of shell commands to perform a particular task, to a complicated set of code modules. I'll allow myself to ramble a bit about ideas I had on this.... Some graph edges might not exist until certain conditions are met. Assume for a moment, the existance of a ".eco" file from PCB listing "Engineering change orders" (back annotation) to go into the schematic. This may add a path to update the schematic, although (off the top of my head), it doesn't _quite_ match the dependency graph of a usual make system - at least not linking back to the schematic... cyclic graphs would spell trouble! In any case, I think some of these targets will need to become smarter about a "up to date" condition than simple timestamps, as it is the actual Engineering data within a file which needs to have changed for any update to be required. If an .eco file demands schematic changes, then manager needs to flag up the process of updating the schematic (perhaps manually) as required until the user has successfully completed it. Assuming no other changes are required, the tool / program called to check if the PCB target needs updating should not necessarily assume it does simply because the schematic's timestamp is newer, even if that former condition does trigger a more expensive test for "up-to-date-ness". In any case.. gEDA is about freedom with workflows. xgsch2pcb is a strange reversal of that, in that its very focused on a particular way of working. It seems to suit student here at CUED, and it mirrors similar tools available with other packages aimed purely at PCB design. For a successful project proposal for a project manager application, for my money at least, it will have to think outside the box a little about how you can support a diverse range of work-flows and targets, ideally not hard-coding too much into the manager its self. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
