Gerbv – a Gerber file viewer

Gerbv was originally developed as part of the gEDA Project but is now separately maintained.

Download

Official releases are published on GitHub Releases. Moreover, CI generated binaries are published on gerbv.github.io.

Be aware however that they are not manually verified!

Current status on packages:

The download-ci page is not updated properly at the moment, but latest build can be downloaded straight from the pipeline at download-actions.

Build

See BUILD.md for how to compile it using CMake with presets.

About Gerbv

• Gerbv is a viewer for Gerber RS-274X files, Excellon drill files, and CSV pick-and-place files. (Note: RS-274D files are not supported.)
• Gerbv is a native Linux application, and it runs on many common Unix platforms.
• Gerbv is free/open-source software.
• The core functionality of Gerbv is located in a separate library (libgerbv), allowing developers to include Gerber parsing/editing/exporting/rendering into other programs.
• Gerbv is one of the utilities originally affiliated with the gEDA project, an umbrella organization dedicated to producing free software tools for electronic design.

About this fork

This is basically a fork of the fork. There have been many chefs trying to fix this soup, but they have never gotten to the bottom of the problems. I (the original creator and maintainer of the gerbv project) have taken over this branch. I gave up the role of maintainer many years ago due to me becoming a consultant with my own business and didn't feel I had time for this.

Since then a lot of things in the software world have revolutionized the way software is developed. From as simple things as Git and github, up to todays AI coding tools. The compilers have become much better at finding problems and errors (you have to enable flags) and also open source tools for static analysis is available.

I have plans on what to do. Some plans may upset people. If this upsets you I welcome you to create your own fork, I see no problems with that.

I have started the develop branch to back out of some completely and utterly useless code formatting changes. There are more serious problems than reformatting the code to some style that is not used anywhere in the code. I admit the code style is broken, but it is really not the first on the agenda to fix. The original main branch will stay as it is for the time being.

My plan for this set of updates

This is a list of things I hope to be able to fix

• [ ] CMake
  • [X] Fix Linux/general CMake target
  • [X] Fix Windows CMake by cross compilation using Mingw64
  • [X] Remove files that are not used anymore or just ancient
  • [X] Make Github pipeline compile the new targets
  • [ ] Fix outstanding tests/targets that are in use on the Github pipeline
    • [ ] Rebuild and deploy website properly (missing variables at the moment)
    • [ ] Enable unit tests
    • [ ] Enable Valgrind (maybe)
    • [ ] Enable Coverage (maybe)
• [X] Fixing first set of trivial bugs
• [X] Packing
  • [X] deb
  • [X] rpm
  • [X] Windows NSIS
• [ ] More updated Gerber specifications
• [ ] Port over to GTK-3.0
• [ ] Fixing misunderstandings of the original specification
• [ ] General documentation
• [ ] Code reformatting

CMake

First step was to switch to modern CMake that uses presets and toolchains. There have been kinks and surprising stuff, but most things are now in place.

We are now in the CI always compiling and building packages for Debian, Ubuntu, Windows (both cross compiled and using MSYS2) and MacOS.

There is now a description on how to compile this project using CMake et al that I recommend you to read.

Fixing first set of trivial bugs

When I was porting the code to CMake I found a bunch of trivial but serious errors. So I fixed them. Upgrading the compiler version have also revealed a number of compilation errors. Now the code compiles cleanly on fairly modern compilers.

Packing

After introducing CMake we are now able to package Debian, Ubuntu and RPMs.

For Windows builds we should use the NSIS toolchain, that is WIP to use NSIS. They are currently zipped together, but downloading it, unzipping and executing it seems to work.

More updated Gerber specifications

When I started this project the "specification" at the time was around 60 pages. Now it is over 200 pages and most things are more clearly defined. And there are updates with new things as well. Hopefully at least try to parse without warnings on missing syntax.

There is (at least was) a lot of broken Gerber files out there. Just look in the examples directory. The question is if it still is so, and if we should support every little quirk, and error or omission.

I have gotten a lot of help in trying to work out all the new Gerbers. It is not all yet, but there are a big bunch of PRs still working on to merge in.

Port over to GTK-3.0

GTK-2.0 is obsoleted since some year(s) back. Already GTK-2.0 have developed since gerbv went there and obsoleted a couple of things that are still used in gerbv. That makes it even harder to update to GTK-3.0.

It is not trivial, a lot of things have changed. There is an excellent patch waiting from @LemonBoy which I have high hopes for. And with a little help from Claude I hope we can pull this together.

The biggest change for gerbv is probably that GDK is removed. That was our fastest drawing frontend. But with faster computers and graphics it hopefully works out OK. If anyone feels adventurous, a frontend using OpenGL is always welcome.

Fixing misunderstandings of the original specification

I am not a graphics guy, I always liked the parsing part more. So from the tiny "standards" paper to the full-blown standards paper of today there are a bunch of things that has been misunderstood or not even implemented.

General documentation

There are today lots of tools to document your code. One great thing I have discovered by switching to a more modern IDE is to document the API of all functions using Doxygen.

This is more of a continuous task. For every file touched some documentation can be updated.

Code reformatting

Of course a code reformatting will be done. This will be a stepwise update, one file at a time. One of the problems with a complete reformatting is the loss of history. You need the history when coming into a project first time to try to understand why something is like it is.

This goes slightly hand in hand with the General documentation updates. Step-wise and when the file is updated for some other reason.

Many other fixes

As the project goes on in rewriting, more and more trivial and not-so-trivial bugs are surfaced. Those will be fixed asap when they are discovered. There can be platforms developers don't have access to, that might delay things. But the urgency will be based on severity.

• Compilation error/warnings. Code should always compile.
• Crashes. Segfaults and similar memory crashes. They can be hard to recreate though.
• Other annoyances.

Building (after CMake transition)

See a more in depth in BUILD.md.

For general Linux distributions

You need:

• gcc
• gtk+-2.0 (use dev package)
• glib-2.0 (use dev package)
• cmake (>=3.28)
• ninja

To configure the build process, run

cmake --preset linux-gnu-gcc

That will create a directory called build with all configuration.

To compile you can choose debug build (default) or release build and then run

cmake --build --preset linux-gnu-gcc

or

cmake --build --preset linux-gnu-gcc-release

There is already an installation process available. You can test it out until I get the energy to write it down properly. It is quite easy if you want to install it under /usr/local. Basically you run

cmake --install build

If you want to install it somewhere else, then YMMV.

Mingw64 cross compilation

Status: compiles

For creating Windows binaries, the Fedora distribution is used. It provides all the development libraries that is needed for Mingw64 cross compilation, especially GTK2.0+ and Cairo.

Compilation has been tested on Fedora 43 with the following libraries installed:

• mingw64-cairo-static
• mingw64-gtk2.static
• cmake
• ninja
• mingw64-gcc
• mingw64-gcc-c++
• gettext

As the binaries are not tested at the moment it might not work or crash horribly. But I would appreciate any report.

The preset is called mingw-w64-gcc and the toolchain file is located in cmake/toolchains/mingw-w64-gcc.cmake.

To configure you do

cmake --preset mingw-w64-gcc

and to compile you do

cmake --build --preset mingw-w64-gcc

Other cross compilations

To create another cross compilation target, check the directory cmake/toolchains/.

To create another preset, check out the directory cmake/preset/ and add the new preset file as an include in CMakePreset.json.

Applied patches from SourceForge

• Patch #77: Fix double-freeing memory, applied in PR#24 as [Commit a96b46](http