Updating the build

[Nimish Telang]

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

[Mark Roszko]

> . 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.

--
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+u...@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.

--

Mark

[Nimish Telang]

It's not the worst I've seen but it needs some maintenance. I’m going to see if I can make it better.

 

> 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.

 

Yep, but it’s hard to explain cmake script updates in the last, say, year ignoring basic cmake features. Cmake has only recently become OK, admittedly.

 

It’s a strong statement since the system is in such a brittle state in contrast to Kicad itself which is better than ever.

 

·         (Heck honestly at work, we wouldn't bother wasting our paid labor on "zombie code" too unless it was an actual problem)

 

Indeed, which is why it’s very, very odd that it’s being carried along.

 

·         The reason why we have forks of the find modules is because we need to support more than your personal build.

 

Quite so, but after bumping the version this is no longer a constraint. Right now, kicad doesn’t support a native build on macOS without considerable hoop-jumping and an entire repo of patched (and subtly buggy in its own way, unfortunately) cmake code; it never supported my 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.

 

Given Kicad breaks user projects, scripts, and data with major upgrades, I have little sympathy for maintaining compatibility for distro maintainers. It’s their problem if they need to backport a modern cmake.

 

·         I'm just going to say you should invest in some liquor, but not the top shelf stuff since you'll want a bunch.

 

I’m in too deep already

 

Nimish

--
You received this message because you are subscribed to a topic in the Google Groups "KiCad Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/a/kicad.org/d/topic/devlist/VLosAq7pSxY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to devlist+u...@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.

[Seth Hillbrand]

On Sun, Mar 19, 2023 at 1:11 PM Nimish Telang <nte...@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.

 Hi,

Mark was trying to politely point you to the fact that this is the wrong way to introduce yourself to a project.  While we recognize that our contributions to KiCad are not without error, crassly denigrating the work contributed by hundreds of dedicated volunteers is rude and wrong.

If you would like to contribute to KiCad's development, we would welcome your efforts.  However, this requires approaching with the understanding that every line of code in KiCad was added for a reason.  And certainly not because the previous contributors, whose shoulders you wish to stand upon were not as clever or insightful as yourself.

You should start very small.  Ask questions.  Learn why things exist before you decide that they don't need to anymore.

Hopefully you will take this to heart an rethink your approach.  We strive very hard to be a welcoming place to code.  You might look over https://dev-docs.kicad.org/en/rules-guidelines/culture/ for details about this.  In particular, please note that we do not engage in rude feedback (e.g. "man-made horror", "without a lot of understanding...", etc).  If you would like to engage in this way, there are probably better projects to do so.

Seth

[Ajith Narayanan]

If KiCad indeed becomes easier to package, we'll know what kind of spirit to thank, besides the personal free time itself.

Not the kind that comes in bottles, I hope 😊

Cheers!

To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/BL3PR04MB79310672B76BC4B3920860B9A7809%40BL3PR04MB7931.namprd04.prod.outlook.com.

[Mark Visser]

Hey Nimish, I'd like to help improve the Mac build system. It's ... painful. And I've been a developer for 25 years. Let me know if you've got a fork somewhere I can pull and help jam on. It shouldn't be this hard to build KiCad.