Mail Archives: geda-user/2016/03/22/05:39:07
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
- Raw text -