kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>