The actual sort doesn't matter as long as it is consistent. I would sort based on the elements being hashed . You will need to fall back to UUID if all points are the same but that is ok because the hash doesn't care
On Fri, Mar 14, 2025, 8:46 AM 'Sean Mollet' via KiCad Developers < [email protected]> wrote: > 1. No, it’s just an alternative PCB export. > 2. I agree that’s the best approach, but I’m unsure of the best way to > sort them. Each item has (for lines anyway, which I’d be fine with just > doing this for lines and letting circles/elipses duplicate) a start point > and an end point. So, we’re sorting a set of lines. Maybe just sort by > PT_A.x, PT_A.y,PT_B.x,PT_B.y? > > > Sean > > > On Mar 14, 2025, at 10:33 AM, 'Seth Hillbrand' via KiCad Developers < > [email protected]> wrote: > > The gencad export is lightly used so your input here is valuable. > > Does the gencad export provide a bom? If so, maybe hashing value is > useful. But clearly hashing refdes is not. > > For the graphical items, I'd use a set to order them before hashing > > Seth > > On Fri, Mar 14, 2025, 7:33 AM '[email protected]' via KiCad Developers < > [email protected]> wrote: > >> >> Problem: >> The gencad export duplicates every footprint regardless of the setting of >> the "Generate a new shape" option. >> >> Cause: >> In export_gencad_writer.cpp (hashFootprint around line 615), footprints >> are hashed to determine duplicates. The hashing has some limitations >> though. First off, it hashes the fields. Those will always be different, >> since it includes the reference. Even excluding the reference, they're >> usually different. Example: 0402 Capacitors. Many different capacitors, >> same footprint, but the export generates a footprint for each. >> >> Next up, the GraphicalItems hashing. This can also be problematic because >> the lines around a footprint can end up saved in a different order, even if >> they came from the same library footprint. I'm not sure of the underlying >> cause here, but it breaks the hashing. >> >> Solutions: >> >> Easiest: >> 1. I think we should eliminate hashing of the fields (remove lines >> 617,618). I can't think of why this is useful. >> 2. For my use, I could also safely eliminate the hashing of graphical >> items (silk screen), since the differences aren't visible anyway. Others >> might disagree on this. >> >> Thoughts: >> >> Field hashing should probably always be removed. It essentially forces on >> the "UsePinNamesUnique" option. >> >> 1. The UsePinNamesUnique option provides a means to get individual >> footprints generated for everything. So, I don't see a big need for the >> hashing function to be super conservative. There's an easy way for a user >> to get a conservative output if they want it. Thus, I'd suggest removing >> both the field hash and the graphical hash. >> >> 2. The next possibility is to remove the field hash and to sort the lines >> of the graphical elements in such a way that they will always output in the >> same order and the hashes will be compatible. I've tried to come up with a >> sort method for this and haven't come up with one. >> >> 3. Add another option to the export called "Precise footprint comparison" >> or similar that enables the graphical hash. Turn it off by default. >> >> I'm happy to produce patches for any of these options, just wanted to >> query the maintainers about what they think is the best approach before I >> built and submitted the patch. >> >> >> >> Thanks, >> >> Sean >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "KiCad Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/kicad.org/d/msgid/devlist/e5d16250-a31d-4487-b3c5-2097347cae20n%40kicad.org >> <https://groups.google.com/a/kicad.org/d/msgid/devlist/e5d16250-a31d-4487-b3c5-2097347cae20n%40kicad.org?utm_medium=email&utm_source=footer> >> . >> > > -- > You received this message because you are subscribed to the Google Groups > "KiCad Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-ozEv2f-GevF5sWP-gR8trbNLrODkbkysZ0rAY5MapJYQ%40mail.gmail.com > <https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-ozEv2f-GevF5sWP-gR8trbNLrODkbkysZ0rAY5MapJYQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > You received this message because you are subscribed to the Google Groups > "KiCad Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/kicad.org/d/msgid/devlist/A9CE256D-8B63-4A7B-9BFA-D71ACFEBFF9D%40malmoset.com > <https://groups.google.com/a/kicad.org/d/msgid/devlist/A9CE256D-8B63-4A7B-9BFA-D71ACFEBFF9D%40malmoset.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-pKuwJf%3D9DpfU_HYmz%2BcGVfFcGKvphs2HZDA7SRPiYdLA%40mail.gmail.com.
