Re: gEDA-user: why separate xgsch2pcb?

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Tue, 2010-02-09 at 19:05 +0000, Peter Clifton wrote:
> On Tue, 2010-02-09 at 18:40 +0000, Peter Clifton wrote:
> > > "Make" is the tool.
> > 
> > Not for a GUI, it isn't. Seriously. Right concept, bad integration.
> 
> There are not enough decent hooks in make to integrate it with a GUI*.
> It is fine if things _work_, otherwise you would have to litter your
> makefile with commands to prod back status to the GUI tool.

I thought I was going to have to really eat my words. Although I don't
know of the stability to this interface, "make -p" dumps the internal
database from make...

Unfortunately, it also executes the "make" process - which is rather a
pain. "make -np" helps, but can't prevent certain side-effects from the
Makefile's variable expansion.

Worst still, having tried this on one of my design projects, I
discovered that make isn't able to tell me if a target is out of date.
It claims to have updated it already, by the time the database is
emitted. "make -dn" gives this kind of info (in text), but this is a
"debug" mode, and probably not something we can rely on as an interface.


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.

The reasons to want this (rather than growing our internal "make"
implementation):

  1. Avoids having to write the "make" algorithm again
  2. Allows the project manager to be based on customisable Makefiles
  3. Allows the GUI to show what (and why) things are out of date.
     - IF.. we could get the info out of "make"!

Reasons to write our own make digraph algorithm:

  1. Probably less work than all the glue needed to interface with external "make"
  2. Less worry about additional tools to be built for Win32
  3. GUI can know which targets are up-to-date, without second-guessing the Makefile
     - Remember, it seems Make can't tell us nicely what is out of date!
  4. Stick it in a library, give the library IPC capability - and let the suite
     tools talk to each other about what files are still open.

Mitigating reasons it isn't evil to writing our own make digraph:

  1. We could (conceivably) write out a Makefile equivalent for the user to use.
  2. If we decided to be masochistic, we could work with Makefiles
     - similarly to how xgsch2pcb works with gsch2pcb files. Probably not a great
       idea though, as we could not realistically hope to re-write make and/or
       support _all_ the syntax make does.
  3. User can still choose _not_ to use the tool!





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