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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp