kicad-developers team mailing list archive

[John Beard <john.j.beard@xxxxxxxxx>]

On Fri, Mar 17, 2017 at 3:16 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> Me neither.  I've never been a big fan of compiling the same source code
> file multiple times (see include/convert_to_bui.h) depending on a
> definition specified at compile time.  I would much rather see some type
> of abstract class be used to define the app specific internal units.  Of
> course you would have to modify the tools to use this object to provide
> the proper internal units.

There shouldn't be /that/ many hardcoded conversions around, most
hopefully use the convert_to_bui.h functions anyway (unless in
common), so most modifications should be centralised.

A simple (but admittedly less elegant and extensible) alternative to
an abstract class may just be an extern that each program wanting to
use units defines. Trying to use the functions in a program that
doesn't define the IU value would be a linker error, much as the
current system requires the macros to be set. The difference it, it
will work in common's translation units too.

>> About the GAL layer, sorry, but I am not a GAL specialist.
>> However I just know this issue is serious and must be solved.
>
> This makes me reluctant to merge this patch even though it sounds like
> this issue already exists elsewhere in the "common" tool framework.  It
> also means that none of the "common" gal tools that use nanometer units
> will be usable in the schematic editor and no I don't think nanometer
> units make any sense for the schematic editor.

This patch doesn't introduce or change any hardcoded conversions that
don't already exist. In fact it only centralises two copy/paste
conversions into one. The rest of the patch should be transparent with
respect to the exact IU value. Once there is a proper conversion
method, the "* 25400" statements just need to be changed for a
function call, which is no different to how it is now.

Cheers,

John