Mail Archives: geda-user/2017/02/16/02:53:31
Hi all,
First of all: I will start using the [dev] tag with my posts that are most
probably not interesting for users. I absolutely accept the user demand
for a separate -dev list, but I have no power to do it. With the tagging I
try to help users to ignore the development threads.
On Wed, 15 Feb 2017, Roland Lutz wrote:
> avoided if possible. I think that if there is any consequence from this, it
> is that we should more actively include contributed backends into the main
> gEDA/gaf repository and add them to the regular test suite.
Sorry, but I have to disagree. Looking from within the gnetlist frame, it
is the logical thing to do. Looking from pcb-rnd or pcb frame, it is the
logical thing to keep it there. Looking from gsch2pcb*'s point, it's
even better to keep it in a 3rd project's frame.
But all these are wrong if we look at the bigger picture.
We currently have 4 gEDA projects that will need to interact in random
ways:
- two variants of gschem/gnetlist/geda/gaf
- two variants of pcb
The fundamental flaw in the above 3 solutions is that we have a glue layer
that needs to know a bit of each project's internals and/or APIs and we
try to put that thing somewhere - either in one of the projects, or in
between. But if anything changes in any of the projects the glue is not
in, it might break.
If it's next to gnetlist, it will break when pcb and/or pcb-rnd changes
any of the import actions.
If it's next to pcb*, it will break if xorn or Vladimir's branch starts
doing something slightly differently.
What do we do long term? Both pcb's starts shipping 2 or 3 versions of the
pcbfwd script (one for xorn, one for Vladimir's, maybe one for the 1.8.x
series?) Or if we move this to the gnetlist side, what do you gnetlist
guys do when pcb and pcb-rnd starts to differ? Shup 2 or 3 versions of the
script? Or do we all restrict ourselves, inhibiting whatever changes
just to keep compatibility with this script? Or add compatibility layers
for this script?
*** PROPOSAL - theory ***
I have a constructive proposal to resolve this issue in a better way. It's
a classic one. Let's split the current glue in two smaller glue layers.
Put a simple interchange file format between the two small glue layers.
One glue layer goes in pcb* and knows the internals/API of the local pcb
version and this file format, but nothing else. The other goes in
gnetlist, and knows the internals/API of the local gnetlist version and
the file format.
From then on, the shared part of our glue and concept is only the common
file fomrat. We can then stop maintaining/worrying about scripts (in our
own repo) that depend on someone else's internals/API/version.
*** PROPOSAL - practice ***
Since I failed to set up a cooperation framework for doing this kind of
design/coordination together, and I prefer to do things instead of turning
them into politics, I just sat down and did this:
- specified the first draft of a real trivial, low cost interchange
format: http://repo.hu/projects/tedax/syntax.html
- specified a netlist block that is capable enough for our current
problem but does not cut off other
flows: http://repo.hu/projects/tedax/netlist.html
- the license of the document is as permissive as possible - mainly
because I hope to get some coverage outside of gEDA
- written a fully working plugin in pcb-rnd for this. Took only like 70
minutes from scratch, with all sort of overhead included. The file format
parser is ~60 lines of C code around fgets() and has 0 dependencies. I
don't think we could get much cheaper than this...
- I expect taking the pcbfwd scm script and modifying it to emit this
format would take less than 30 minutes for anyone experienced with these
sort of things. It's because emitting it is even cheaper than parsing
it.
- we can add this as an extra, as an alternative, without having to
interfere with our old ways; we can do it right now, we don't need to
wait for anything; then if we see it works, we can lean back and see the
old pcbfwd model to slowly phase out by itself. It works even if we don't
do it all at once, even if only 2 or 3 of the projects starts to support
it soon and the rest follow later.
*** PROPOSAL - actions ***
I'd like to kindly ask you (Roland, Vladimir, pcb-mainline devs) to follow
my efforts and implement your part in your projects respectively.
For doing the gnetlist side: you can already use pcb-rnd from trunk/ to
test, but I offer that I run your files through my copy of pcb-rnd if that
helps.
For pcb mainline: I believe you can copy most of my plugin code, replacing
the hash lib with glib; the netlist example in the doc should work as an
input, maybe with some minor tweaking on the footprint names (I used that
file too).
I am also open for suggestions regarding to the format _within the
existing scope_: http://repo.hu/projects/tedax/ - so please don't suggest
to use json, xml, verilog or whatever instead - that would not be a
suggestion to this effort but a proposal for a totally different one
(which is okay, just make a separate thread for that please).
Best regards,
Igor2
- Raw text -