X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 22 Mar 2016 10:43:15 +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: Re: [geda-user] mucs autorouter In-Reply-To: Message-ID: References: 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 On Tue, 22 Mar 2016, Kai-Martin Knaak wrote: > gedau AT igor2 DOT repo DOT hu wrote: > >> Input: http://igor2.repo.hu/tmp/tut.pcb (+ a netlist) >> Output: http://igor2.repo.hu/tmp/tut_routed.pcb >> >> I could invest some more hours and rewrite the util to be a plugin. > > IMHO, plugins are a less than optimal concept in the case of low volume > low traffic projects like pcb and EDA in general. In particular, the way > plugins are done in pcb presents enough additional obstacles that I tend > to not use them at all. Plugins need to be compiled separately for each Fortunately plugins are defined a bit differently in pcb-rnd. We celarly don't agree on the role of plugins; in pcb-rnd I'm investing time in splitting up the core and moving much of it into core plugins so the user can decide which features should be compiled or even dynamic linked. > version of pcb. There is no mechanism to pick automatically the "right" > binary. Since I like to use both, the stable version from stock Debian and > bleeding edge from git head I end up with plgins not working half the I think I have a solution for this in pcb-rnd: if I need to keep two versions of pcb-rnd, I install them under different paths and each have its own plugin binary dir. It also handles the case of multi-arch, looking in arch-suffixed plugin dirs. > time. In addition, plugins do not track advances of the main source. So > they bit-rot and tend to "go away". Well, we are talking about core plugins here. They are in the same svn as pcb-rnd and maintained together with the rest of the code. The chance such a plugin not tracking the core is exactly the same as the chance of any #ifdef'd core code not tracking the rest of the core. That is: if developers have the plugin or #ifdef'd code turned off, they don't notice a change in core broke them. So 0 difference in maintaining or bit-rot with core plugins for developers; the real diff is for the user, control over what is compiled and how it is linked is much more fine grained. > >> The question is whether it is worth the effort. > > Yes, please! > Biased routing would be very welcome by me. I'd even consider to overcome > my learned resistance toward plugins. Ok, so +1 for the mucs experiments. Btw, whether it'd be a plugin in pcb-rnd is no question (it would be, for sure). Whether the same code would be a plugin or core function in mainline pcb is up to pcb developers. So all the above plugin vs. non-plugin thing is mostly off-topic. I used the word plugin in the original mail to suggest the new code would be "code not tightly coupled with core". > > >> More generally, do anyone like the example output? Or the idea of >> the "biased layers" (hirozontal traces on one layer, vertical on >> another, plus a lot of vias)? > > Biased routing is what I teach students as a default strategy for manual > layout. It automatically prevents the most common blunders: Big road > blocks due to parallel tracks on both sides of a two-layer layout. The > result is reasonably close to optimum most of the time. Our preferred fabs > do not charge extra for additional vias (unless they come in ridiculous > amounts) Good to know, thanks! Regards, Igor2