Index: trunk/doc/developer/plugin_conf.h =================================================================== --- trunk/doc/developer/plugin_conf.h (revision 20497) +++ trunk/doc/developer/plugin_conf.h (nonexistent) @@ -1,14 +0,0 @@ -#ifndef PCB_VENDOR_CONF_H -#define PCB_VENDOR_CONF_H - -#include "conf.h" - -typedef struct { - const struct plugins { - const struct vendor { - CFT_BOOLEAN enable; /* Enable vendor mapping */ - } vendor; - } plugins; -} conf_vendor_t; - -#endif Index: trunk/doc/developer/plugin_core_simple.html =================================================================== --- trunk/doc/developer/plugin_core_simple.html (revision 20497) +++ trunk/doc/developer/plugin_core_simple.html (nonexistent) @@ -1,68 +0,0 @@ - - -

pcb-rnd hacking - simple core plugins

- -

Introduction

- -

Setting up a new core plugin

1. make up a name for the plugin. There are a few conventions. This document will refer to the name as plg, always replace it with your chosen name. -
2. cd src_plugins; svn mkdir plg -
3. copy Makefile, Plug.tmpasm and .pup from another, small plugin, for example from the report plugin (the next points will assume you picked this plugin as the source of the copy) -
4. edit Makefile: replace report to plg -
5. edit plg.pup; there should be short summary about the purpose of the plugin then "#key: value" pairs for statistics: -
- $class the same as the plugin name prefix (see conventions. ) or (feature) for feature plugins; it's redundant but is kept for supporting external plugins - see mods3 for a short list of all classes -
- $short short description - should be less than 32 characters; this shows up in the configure summary -
- $long long description - used for documantation; no length limitation, but must be a single line -
- $state works, WIP, abandoned or deprecated - see mods3 for explanation -
- $lstate [optional] a chance to explain why the value of default is what it is; e.g. why a plugin is disabled -
- $package when pcb-rnd is packaged for a distribution or OS, which package this plugin should end up in (see also: trunk/doc/developer/packaging/) -
- $fmt-native only for io_ plugins: whether this format is considered native (see also: io_lihata's pup) -
- $fmt-feature-r only for io_ plugins: a read/load feature supported by the plugin (multiple entries of this should be added; see also: io_lihata's pup) -
- $fmt-feature-w only for io_ plugins: a write/save feature supported by the plugin (multiple entries of this should be added; see also: io_lihata's pup) -
- default disable-all or disable or buildin or plugin -
- dep [optional] a single plugin name on which plg depends; multiple dep lines can be added -
- conflict [optional] a single plugin name on which plg conflicts with; multiple dep lines can be added -
- autoload [optional] when 1, the plugin is automatically loaded and initialized (when not disabled); do not set this on libs and other code that are accessible only as a dependency of other plugins; set this 1 on HID, io, import, export, feature plugins -
- Values of default: -
-
6. edit Plug.tmpasm: -
```
-put /local/pcb/mod {plg}
-put /local/pcb/mod/OBJS [@ $(PLUGDIR)/plg/foo.o $(PLUGDIR)/plg/bar.o @]
-put /local/pcb/mod/CONF {$(PLUGDIR)/plg/foo_conf.h}
-put /local/pcb/mod/YACC [@ $(PLUGDIR)/plg/bary @]
-put /local/pcb/mod/LEX  [@ $(PLUGDIR)/plg/barl @]
-		
```
- -
- /local/pcb/mod: the name of the module we are compiling -
- /local/pcb/mod/OBJS: a space separated list of object files to compile -
- /local/pcb/mod/CONF: optional: the name of the conf struct header - if the plugin doesn't have runtime configuration settings, remove this line -
- /local/pcb/mod/YACC: optional: if you have files for yacc-processing, list them without the .y suffix here (space separated) -
- /local/pcb/mod/LEX: optional: if you have files for lex-processing, list them without the .l suffix here (space separated) -
- Leave the switch part on the bottom intact. -
-
7. create your C sources and headers in src_plugins/plg/ - The order of entries in the file is the same as the order in the summary table - at the end of ./configure; insert your plugin in the right group! -
8. run "make map_plugins" in src/ to get your new plugin on the plugin list -
9. run ./configure --buildin-plg -
10. run make to see if it compiles and test -
(11. while developing, you can run make from src_plugins/plg - if - your plugin is a builtin, it will recompile pcb-rnd. For some of us it's convenient - to run make in the same directory where all the source files are.) -

- - - Index: trunk/doc/developer/plugin_naming.html =================================================================== --- trunk/doc/developer/plugin_naming.html (revision 20497) +++ trunk/doc/developer/plugin_naming.html (nonexistent) @@ -1,16 +0,0 @@ - - -

pcb-rnd hacking - plugin naming conventions

export_: export plugins start with export_; these render to a non-native format that can not be then loaded -
import_: import plugins start with import_; these perform partial data load from alien formats (typically: netlist/schematics) -
io_: full board save/load prefixed with io_; even if your plugin can now only load or save, if it's possible to do a load-save-load round-trip without data loss, it's an io_ -
hid_: interactive, often GUI, frontends are prefixed with hid_ -
fp_: footprint access plugins start with fp_ -
lib_ plugins are libraries used by other plugins; they are disabled by default and are enabled through the plugin dependency system -
act_ plugins are stateless wrappers to expose existing C functions (moslty core functionality) over the action API (for scripts and users) -
ar_ plugins are related to external autorouting: they are reponsible for calling the external process and coordinate the routing but sometimes also implement export/import pair for the format -
anything else is considered a feature plugin and has no specific prefix. -

- - Index: trunk/doc/developer/plugin/conf.h =================================================================== --- trunk/doc/developer/plugin/conf.h (nonexistent) +++ trunk/doc/developer/plugin/conf.h (revision 20498) @@ -0,0 +1,14 @@ +#ifndef PCB_VENDOR_CONF_H +#define PCB_VENDOR_CONF_H + +#include "conf.h" + +typedef struct { + const struct plugins { + const struct vendor { + CFT_BOOLEAN enable; /* Enable vendor mapping */ + } vendor; + } plugins; +} conf_vendor_t; + +#endif Index: trunk/doc/developer/plugin/core_simple.html =================================================================== --- trunk/doc/developer/plugin/core_simple.html (nonexistent) +++ trunk/doc/developer/plugin/core_simple.html (revision 20498) @@ -0,0 +1,68 @@ + + +

pcb-rnd hacking - simple core plugins

+ +

Introduction

+ +

Setting up a new core plugin

1. make up a name for the plugin. There are a few conventions. This document will refer to the name as plg, always replace it with your chosen name. +
2. cd src_plugins; svn mkdir plg +
3. copy Makefile, Plug.tmpasm and .pup from another, small plugin, for example from the report plugin (the next points will assume you picked this plugin as the source of the copy) +
4. edit Makefile: replace report to plg +
5. edit plg.pup; there should be short summary about the purpose of the plugin then "#key: value" pairs for statistics: +
- $class the same as the plugin name prefix (see conventions. ) or (feature) for feature plugins; it's redundant but is kept for supporting external plugins - see mods3 for a short list of all classes +
- $short short description - should be less than 32 characters; this shows up in the configure summary +
- $long long description - used for documantation; no length limitation, but must be a single line +
- $state works, WIP, abandoned or deprecated - see mods3 for explanation +
- $lstate [optional] a chance to explain why the value of default is what it is; e.g. why a plugin is disabled +
- $package when pcb-rnd is packaged for a distribution or OS, which package this plugin should end up in (see also: trunk/doc/developer/packaging/) +
- $fmt-native only for io_ plugins: whether this format is considered native (see also: io_lihata's pup) +
- $fmt-feature-r only for io_ plugins: a read/load feature supported by the plugin (multiple entries of this should be added; see also: io_lihata's pup) +
- $fmt-feature-w only for io_ plugins: a write/save feature supported by the plugin (multiple entries of this should be added; see also: io_lihata's pup) +
- default disable-all or disable or buildin or plugin +
- dep [optional] a single plugin name on which plg depends; multiple dep lines can be added +
- conflict [optional] a single plugin name on which plg conflicts with; multiple dep lines can be added +
- autoload [optional] when 1, the plugin is automatically loaded and initialized (when not disabled); do not set this on libs and other code that are accessible only as a dependency of other plugins; set this 1 on HID, io, import, export, feature plugins +
+ Values of default: +
+
6. edit Plug.tmpasm: +
```
+put /local/pcb/mod {plg}
+put /local/pcb/mod/OBJS [@ $(PLUGDIR)/plg/foo.o $(PLUGDIR)/plg/bar.o @]
+put /local/pcb/mod/CONF {$(PLUGDIR)/plg/foo_conf.h}
+put /local/pcb/mod/YACC [@ $(PLUGDIR)/plg/bary @]
+put /local/pcb/mod/LEX  [@ $(PLUGDIR)/plg/barl @]
+		
```
+ +
- /local/pcb/mod: the name of the module we are compiling +
- /local/pcb/mod/OBJS: a space separated list of object files to compile +
- /local/pcb/mod/CONF: optional: the name of the conf struct header - if the plugin doesn't have runtime configuration settings, remove this line +
- /local/pcb/mod/YACC: optional: if you have files for yacc-processing, list them without the .y suffix here (space separated) +
- /local/pcb/mod/LEX: optional: if you have files for lex-processing, list them without the .l suffix here (space separated) +
- Leave the switch part on the bottom intact. +
+
7. create your C sources and headers in src_plugins/plg/ + The order of entries in the file is the same as the order in the summary table + at the end of ./configure; insert your plugin in the right group! +
8. run "make map_plugins" in src/ to get your new plugin on the plugin list +
9. run ./configure --buildin-plg +
10. run make to see if it compiles and test +
(11. while developing, you can run make from src_plugins/plg - if + your plugin is a builtin, it will recompile pcb-rnd. For some of us it's convenient + to run make in the same directory where all the source files are.) +

+ + + Index: trunk/doc/developer/plugin/naming.html =================================================================== --- trunk/doc/developer/plugin/naming.html (nonexistent) +++ trunk/doc/developer/plugin/naming.html (revision 20498) @@ -0,0 +1,16 @@ + + +

pcb-rnd hacking - plugin naming conventions

export_: export plugins start with export_; these render to a non-native format that can not be then loaded +
import_: import plugins start with import_; these perform partial data load from alien formats (typically: netlist/schematics) +
io_: full board save/load prefixed with io_; even if your plugin can now only load or save, if it's possible to do a load-save-load round-trip without data loss, it's an io_ +
hid_: interactive, often GUI, frontends are prefixed with hid_ +
fp_: footprint access plugins start with fp_ +
lib_ plugins are libraries used by other plugins; they are disabled by default and are enabled through the plugin dependency system +
act_ plugins are stateless wrappers to expose existing C functions (moslty core functionality) over the action API (for scripts and users) +
ar_ plugins are related to external autorouting: they are reponsible for calling the external process and coordinate the routing but sometimes also implement export/import pair for the format +
anything else is considered a feature plugin and has no specific prefix. +

+ +