[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: why separate xgsch2pcb?
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...
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. It could be a GUI based on a
config file that is one of several users can choose from a
project manager. The (GUI/command line) project manager could
also have code, (and GUI), that simplifies creation of alternate configs
so several styles of work-flow could be shipped and turned on in a flash.
Launching gschem from the project manager might overwrite some gschemrc
and gafrc files when it runs the first time, (and those could have GUI
warnings pop up), so as to keep it quick start for newbies. One obvious
work-flow style to use is the "project dir" concept, (John Doty), so
running make updates symbol files and maybe even footprints some day,
all without stepping on standard library symbols or footprints.
John
--
Ecosensory Austin TX
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user