The existence of the `thirdparty` folder is purely because we want a locked-in time snapshot of sources with numerous bugfixes we make over time. We don't want upstream packages because upstream is either dead, or too much of a pain to deal with.
> It eases version control and reduces the cmake package finding process. Uhh, there is absolutely nothing wrong with our current cmake process. I see no complexity unless you are nitpicking over a few extra lines of code. It complicates version control specifically because we want to make bug fixes and changes on the fly to these libraries, but now suddenly we have to officially tag and maintain them in separate repos, that is way more work than any of us want to put in for no real benefit. It already builds completely painlessly, why would we want to make this complicated? On Wed, Jan 5, 2022 at 7:10 AM Timo Werner <t....@gmx.de> wrote: > Hi! > > I'm new here, so please excuse if this question was already answered. I > couldn't find anything on the mailing list. > > I recently made some good experiences with the conan package manager. It > eases version control and reduces the cmake package finding process. > > I'd like to ask whether someone tried already or if conan should not be > taken into account for kicad anyway. If you think I could give it a try, > I'd implement conan support for some of the third party sources in > thirdparty folder. > > Enjoy! > > Timo > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > -- Mark
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp