PCB is developed by volunteers. As with any volunteer project, we always can use more help. This page tries to give some guidelines on how to more effectively help out.
See Reporting Bugs for information on where to report bugs and how to make an effective bug report.
- Use the GNU Coding Standards for source code formatting. You can use the indent program to help reformat your code.
- Your code should compile cleanly without any compiler warnings. In the past we have found and fixed many bugs by simply paying attention to the compiler warnings. Warnings that don't indicate real bugs end up encouraging people to ignore all the warnings.
- Changes which require the use of an additional library or tool are discouraged. If there is a really good reason, then adding a dependency is not out of the question. However we don't want to add extra baggage unnecessarily.
- Changes which add new export options or new exporters should add appropriate entries to the test suite.
- When you submit your patch to the patch tracking system, please log in. This allows you to receive a notification when additional content is added to the ticket or if its status changes. It is also useful when seeking feedback to see if a particular bug has been fixed. Just including your email and posting without logging in causes additional work for the developers.
PCB includes a test suite. Currently the test suite does not check the GUI but it does check the various exporters. The test suite is in the pcb/tests directory. The README.txt file there has complete documentation on how to use the test suite and how to add to the test suite.
If you add a new exporter or if you add command line options to an existing exporter you must add a test suite entry. Similarly if you find a bug in one of the exporters, the preferred procedure is to add a test suite entry which demonstrates the bug, fix the bug, and then verify that the test suite shows proper functionality.
When a new test is added it is important to try and make it as simple and modular as possible. In other words, if there is a problem with a particular footprint not exporting correctly, then make a test suite entry with just that footprint or a simplified view of that footprint. Don't just use a board with a thousand other components on it because it makes debugging much harder.
PCB uses "actions" internally to do much of the work. An "action" can be thought of as a simplified function. All of PCB's actions are fully documented in the PCB manual. If you add any new actions, then you must add the appropriate documentation. The documentation for all actions is embedded in the source code using specially formatted comments. Search for the string "%start-doc" in the existing source code for many examples. This documentation is later automatically extracted when the manual is built.
If your changes add to or modify the behavior of PCB in a way which is not simply a bug fix, then update or add to the manual. The PCB manual is in the doc/ directory from the main source tree.
Do not change any file formats unless absolutely required. If you do make a change to the file format (the parser is in src/parse_y.y then you need to update the PCB_FILE_VERSION macro in src/file.h. The .pcb file format may not be changed in a way that prevents PCB loading any older file formats
If you must change the file format, then the structured comments in src/parse_y.y must be updated to reflect the change. This is how the manual section on file formats is generated.