Hi Simon, Thanks for the update. I will continue with my work as planned. I think the only conflict will be in the include/convert_to_biu.h which will only be the schematic units section.
Cheers, Wayne On 6/25/2019 3:16 PM, Simon Richter wrote: > 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
