kicad-developers team mailing list archive

[Ian McInerney <ian.s.mcinerney@xxxxxxxx>]

I would be against moving our bundled third-party dependencies to conan
because then it adds a configure-time need for an internet connection to
download them as packages (unless we add additional logic to allow building
using a local copy, but that will increase the complexity of our build
scripts more, which seems antithetical to the purpose of the change.).
Additionally, this change would be harmful to our linux packagers, because
almost all official packages must build with no internet access during the
configure/build stages.

I also don't see any developer gain in this idea. Our current build system
for the third-party directory just requires a single CMakeLists.txt file
that defines a library target inside the appropriate third-party
subdirectory, so there is no need to use any find_package() calls or any
other CMake methods to add those packages.

-Ian

On Wed, Jan 5, 2022 at 12:11 PM Timo Werner <t.w92@xxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>