> . There's a lot of zombie code being carried in the Kicad repo for unclear gain
Welcome to the world of stuff that works and is low hanging fruit for a bunch of people doing this out of their personal free time. (Heck honestly at work, we wouldn't bother wasting our paid labor on "zombie code" too unless it was an actual problem) However, be warned, zombies do bite and go for the brain. > It's clearly been accreted over the years without a lot of understanding of what cmake can do. That's a pretty strong <expletive> statement to come in with. KiCad has used cmake since 2007. CMake has changed A LOT in that time and it was actually a lot less capable in the past. Not to mention just being a mess across platforms compared to how well it works now. > This also helps other systems since fewer stuff is added globally, and there's less system-specific code in Kicad itself. The reason why we have forks of the find modules is because we need to support more than your personal build. Typically, the problem was certain Linux distros running behind by quite a few years when it came to cmake versions. Ubuntu and Debian being the biggest culprits. We cannot force those distros to download newer cmakes outside of their package manager ecosystem. Currently we have managed to bump that requirement to 3.21 luckily and that's a pretty recent and big jump from the previous 3.12 for last year. > Kicad should not be this difficult to package. I'm just going to say you should invest in some liquor, but not the top shelf stuff since you'll want a bunch. On Sun, Mar 19, 2023 at 4:11 PM Nimish Telang <ntel...@gmail.com> wrote: > Hi, > > The current Kicad build cmake code is a man-made horror beyond my > comprehension. It's clearly been accreted over the years without a lot of > understanding of what cmake can do. Admittedly cmake itself is the cause of > most of the horror, but we can do better. > > I'm no cmake expert, but a few days of fixing the code has yielded some > decent improvements. I expect more significant modularization changes to > happen as well as the dependency graph is made more explicit. There's a lot > of zombie code being carried in the Kicad repo for unclear gain, or for > reasons that no longer apply in 2023. > > Having to use kicad-mac-builder is also another pain to get kicad building > on a Mac, and it is gating my ability to improve Kicad itself. It works, > but isn't actually needed if the cmake is written correctly. This also > helps other systems since fewer stuff is added globally, and there's less > system-specific code in Kicad itself. > > I'll also look into rebuilding the install/bundle/app code, as that's its > own mess. Kicad should not be this difficult to package. > > Nimish > > -- > 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 devlist+unsubscr...@kicad.org. > To view this discussion on the web visit > https://groups.google.com/a/kicad.org/d/msgid/devlist/490e5cea-ff23-4b23-948f-62e88876a916n%40kicad.org > <https://groups.google.com/a/kicad.org/d/msgid/devlist/490e5cea-ff23-4b23-948f-62e88876a916n%40kicad.org?utm_medium=email&utm_source=footer> > . > -- Mark -- 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 devlist+unsubscr...@kicad.org. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAJjB1qLBD%2BcCmo-VOmwODYNdzGuoFefb2YixO7FT%3DyPDJ59iPg%40mail.gmail.com.
