Re: gEDA-user: why separate xgsch2pcb?

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Wed, 2010-02-10 at 11:38 -0600, John Griessen wrote:
> Peter Clifton wrote:
> > It was hoping it would be possible to prod "make" to get enough
> > information back to the project manager as to which targets need
> > updating etc., which you could then call "make" to update.
> > 
> > I also wanted to be able to extract the digraph make constructs - so the
> > GUI can display _why_ something is out of date.
> 
> Why would a GUI need to display this kind of status?  Every time you
> touch something in gschem, several data files are "out of date" instantly.
> You could know that things are always "out of date" until the project is done
> and not worry about it -- except for pressing the make button often...

That is a good question, and I don't have a definitive answer for it.
Having used various GUI project managers - I've found the feature quite
useful in those which show the up-to-date status of individual targets.

Personally, I don't think forcing the user to prod a "make" button all
the time in order to know their work is up to date, is a good interface.
Nor is it necessarily possible for us to poll make on the user's behalf.

Some update processes can take absolutely ages to run (HDL synthesis?),
and some might trample on open files with changes. I might want to know
if I'm up-to-date without necessarily doing anything about it.


An interesting question is this.. (say) for the gschem -> PCB work-flow,
at what point do you consider the PCB to be "up to date"? Is it once the
user has saved the board - later than the schematics, or is there some
deeper criterion about the layout matching the netlist, and passing DRC?

Probably the simplest approach (which I'm leaning towards) is to treat
the netlist file as the target, keep that up-to-date, then let PCB deal
with prompting the user to incorporate changes when it spots changes to
the netlist on disk. The PCB file would still likely be a dependency of
other targets, such as CAM output files - which become out of date once
the user modifies the board. (But not immediately when schematics
change.)


> I can't see why a GUI that drives make, (and writes on the Makefile.in),
> is anything bad -- it would be the valuable organization aid to newbies
> without hampering individual style.

Not bad - e.g. Anjuta does an excellent job of this for a programming
IDE. With EDA though, our targets are not necessarily volatile -
especially if you get into processes which try to "update" the user's
existing design files. This is perhaps something to address from the
view of how these update processes are structured.


Best wishes,

Peter C.





_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user