1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
<html>
<head>
<title> pcb-rnd modularization </title>
</head>
<body>
<H1> pcb-rnd modularization </H1>
<H2> Why bother... </H2>
I believe good software should be modular. This is especially important in
the context of large software, such as CAD applications. There should be
a thin core that can model the world and provide the basic operations defined
on it but anything else should go in separate modules.
<p>
Fortunately PCB already had a strong infrastructure supporting this idea.
It has dynamic loadable plugins and the GUI and exporters are in separate
HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
gpmi module as a separate plugin.
<p>
In version 1.0.8 to 1.1.0 a considerable chunk of core code has been moved into
<i>core plugins</i>. A <i>core plugin</i> is just a plugin that is
maintained together with the core, in the same repository, still the code is
somewhat detached from the core. More importantly, the user can choose, for
each plugin, separately:
<ul>
<li> to compile it as a buildin (static-link it into the pcb executable)
<li> to compile it as a plugin (dynamic-link it runtime, if the .so is installed in the plugins/ directory)
<li> to disable the plugin, so it is not compiled at all
</ul>
<p>
I believe such modularization has benefits on multiple levels:
<ul>
<li> it is possible to compile smaller, potentially faster executables by omitting features the specific user would never use anyway
<li> in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
<li> such plugins have to have some sort of APIs if they want to reference each other or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
</ul>
<H2> Progress in charts </H2>
<h3> Before-after </h3>
All numbers are in <a href="http://en.wikipedia.org/wiki/Source_lines_of_code">SLOC</a>
and are acquired running sloccount on the given directory. While lines of
code alone is not a true measure of complexity, it's a good estimation. The
slices of pie charts are the major components of the pcb-rnd executable.
<table border=1 cellspacing=0> <tr><td>
<table border=0>
<tr><td><img src="before.png"><td> <td><img src="after.png">
<tr><td>Before modularization: pcb-rnd version 1.0.7
<br>Note: gpmi was already a plugin
<td>
<td> After modularization: current pcb-rnd
<br>Note: gpmi is part of the "plugins" slice
</table>
</table>
<h3>Zooming on to the plugins</h3>
<p>
<table border=0 width="100%">
<tr>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="mods.png"><tr><td><b>total size per class</b></table>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="io.png"><tr><td>IO plugins</table>
</table>
<table border=0 width="100%">
<tr>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="feature.png"><tr><td>feature plugins </table>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="export.png"><tr><td>export plugins</table>
</table>
<table border=0 width="100%">
<tr>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="hid.png"><tr><td>HID plugins</table>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="import.png"><tr><td>import plugins</table>
</table>
<table border=0 width="100%">
<tr>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="lib.png"><tr><td>library plugins </table>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="fp.png"><tr><td>footprint plugins</table>
</table>
<p>
(Red means the plugin doesn't really work).
<H2> Progress in numbers </H2>
Below is a table with the summary of core plugins.
<table border=1 cellspacing=0>
<tr><th>module <th>size [sloc] <th> status <th> configure<br>default <th> class <th> description
|
