X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Thu, 16 Feb 2017 08:52:17 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: [dev] proposal: new gschem -> pcb flow (was: Re: [geda-user] Recent gschem-PCB import problem?) In-Reply-To: Message-ID: References: <1487162236 DOT 3011 DOT 9 DOT camel AT linetec> <1487176819 DOT 3011 DOT 27 DOT camel AT linetec> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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