kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

Hi Wayne,

On Tue, Jun 25, 2019 at 12:36:36PM -0400, Wayne Stambaugh wrote:

> I guess I should comment on this seeing that I am the project leader.  I
> am fine with refactoring as long as it's an improvement over existing
> code.

The main improvement is going to be that we can dump the preprocessor magic
for the internal units, which then allows us to share binary code between
different kifaces, so we can turn common into a shared library.

With that:

 - binary size is halved
 - qa_common tests can be merged
 - tests can be linked against a shared library (way faster)
 - the python module can be linked against a shared library
 - we no longer have different functions with the same name (great for
   debugging)

So yes, I think that'd be worth it. Getting nice unit names and some type
safety is just the icing on the cake (but necessary for refactoring, so the
compiler can tell us where the next change needs to be made).

> What changes are you planning for units and when do you expect to have
> this done?  I just branched myself to port the schematic internal units
> to 100nm in preparation for the new file formats so I'm sure there is
> going to be conflicts.  If you are almost ready to merge, I can wait but
> I'm ready to get started on this so I would rather not wait too long.

My approach for the length units can be merged incrementally, so there is
an intermediate stage where it will convert between "old" and "new"
internal units at the boundaries (by multiplying or dividing with the
appropriate factor according to the -D flag from the command line) and
issue a warning "refactor here".

So I can effectively rebase my branch on top of whatever changes you have,
the compatibility code will keep it working. Merging would happen in
multiple stages anyway, with the compatibility code remaining in place
until everyone's development branches are merged or rebased.

That's why I listed

> > Replacing points will be too big to do in a single commit, so:
> > 
> >  - create strong types for lengths and points [needs rework]
> >  - literal handling with unit suffix [mostly done]
> >  - compatibility code for automatic conversion to existing formats [mostly
> >    done]
> >  - piecewise replacement of existing coordinate code
> >  - remove compatibility code
> >  - remove old code
> >  - remove -DEESCHEMA, -DPCBNEW etc.
> >  - merge pcbcommon into common

Each of these steps live in separate commits, and every commit takes us
from a working state to another working state.

   Simon