I have written instructions for building KiCad on different Linux distros. At the moment there are instructions for Ubuntu etc., openSuSE Tumbleweed and Fedora.
The point of these instructions are that you don’t have to try to find out what to install to satisfy all dependencies. Basically all the dependencies come with one command line command.
The pre-requirement is to be able to have or add a repository for your distro which has an up to date version of KiCad package.
Tumbleweed is the testing ground of what will become Leap 15.3 in June or July. Currently 5.1.9 binary packages are already in Tumbleweed, but I’m not sure if it has Py3 support which is the main deficiency in 15.2’s packages. Download links are here:
Perhaps the maintainer just needs some help or nudging to incorporate Py3 support. I don’t know if it were added it would be allowed as an update post-freeze and pre-release. But it could go into a non-official (Experimental or Community) repository.
5.1.10 update automatically came through for Leap 15.2, another reason to have one maintainer build binary packages rather than everyone trying to build from source. If you do get the ear of the maintainer, maybe you could suggest building delta RPMs as well which reduce the download enormously for large packages like the 3D footprints.
I’m more interested about continuously following the development than building stable releases. I really don’t see a reason to build releases unless they are not packaged (or the packages are missing something which can be built). I hope the instructions are useful for those who for some reason or another want to build from source and maybe test merge requests, play with the source code, start developing or discuss and test bug fixes “real time”. Even packaged nightly builds are sometimes too slow for communication.
BTW, I think Tumbleweed packages have pyhon3 enabled.
Good. However to widen the use of KiCad there needs to be more people in the package maintainer layer for various distributions because most people enjoy the benefits of subscribing to repos and are not interested in going back to the days when nerds were nerds and computers quaked at their approach.
Even for the nerdy it can still be useful to leverage off the build infrastructure some distros provide with nightly builds, CI, etc.
This guide for arch linux feels kind of weird to me:
What was the reason why makepkg is only used for downloading and extracting the source?
If you just do makepkg and pacman -U to install the resulting package, some user error can be avoided, and kicad can then be uninstalled by pacman if need be.
Thanks !
Too bad, I just finished compiling Kicad (Linux Mint) but spent hours collecting the dependencies (the hard way…) Never been able to install Phoenix (disabled some wxScrpting options)
I just start a new compile, using your Ubuntu instruction.
The automatic dependencies management is really great.
If your purpose is only to follow the latest master branch, you can as well use kicad-git from AUR in the standard way through the package manager. Makepkg is needed only if you want to change the source code or build flags.
EDIT: I made that statement a bit more prominent in the page.
I still don’t think I fully agree, or at least it seems weird to me. makepkg && pacman -U is the supported way to build and install AUR packages on Arch, and anyway that’s what a AUR helper like yay or paru would be doing behind the scenes when it installs kicad-git.
I guess I see a few use-cases here, with your documentation somewhere in an awkward middle spot:
I just want to use 5.99 on Arch/Manjaro, in which case I would install kicad-git or more likely kicad-nightly from AUR [your statement addresses this]. In this case I would use yay, or bare makepkg to build the package followed by pacman to install it.
I want to install a specific commit, or a patched build. In this case I would start following your instructions but then diverge: I would customize the PKGBUILD with the specific commit and/or patches necessary, then run makepkg and pacman to build and install my customized build.
I’m developing kicad, in which case I just want a development build environment but I don’t want to install my builds. In this case I would just do a clone of the git repository from gitlab and set up the CMAKE flags myself. I have to make sure all the dependencies are installed, but that’s done already if I’ve done option 1 above (or probably even if I’ve installed the prebuilt kicad 5.1 package – Arch doesn’t have separate -dev packages like many other distributions).
So I guess it just seems weird to me to start to build a package but then not get any of the advantages of the package manager That said, I understand that it’s a relatively easy way to ensure the build environment is setup correctly, so maybe that makes sense for people getting started with doing their own builds. It’s just not the way I would do it.
Edit: actually thinking about it more, I would not have thought to do it this way but I kind of like it as a way to make sure your build environment is set up correctly. “the easy way” like you say. Kudos
I agree with the criticism. The Arch system is a bit different from other (binary) distros. I was even tempted to replace the whole article with “Arch users don’t need any instructions and if they do they aren’t allowed to ask because it’s already documented somewhere”
I wanted the instructions be consistent so that the configuring, installing and running are as similar as possible between distros, and only the dependence tracking is distro specific. Again, Arch works a bit differently so this may not be optimal.
Additionally, I’m new to Arch/Manjaro and learned them only because I wanted to try the procedure and document it. So there may be better ways to do it. (BTW, now I have installed and tried at least 8 distros. Manjaro was the only one which got me excited positively, with the Arch architecture combined with style and usability. Yet Kubuntu stays my favorite which I will use.)
It’s possible to use one call to makepkg to download and extract the sourcecode. Next the user can alter the sourcecode any way they like, use a second call to makepkg to build the package, and finally use pacman -U to install the resulting package. Would this be an acceptable approach?
Disclaimer: I have not actually tested the below commands:
makepkg -o // Download and extract files only
<< edit the sourcecode >>
makepkg -e //Do not extract source files (use existing $srcdir/ dir)
pacman -U kicad…xz
This Arch Linux user (me) is not as smart as you might think. I very much enjoy step-by-step instructions, especially from start to finish. The official Arch Linux wiki shows very detailed instructions, but not start-to-finish ones, as they don’t like overlapping (and therefore redundant) documentation.
I wanted to suggest that you add the following to the wiki page:
- If you need to debug a bug you are finding in KiCad, or even in your own merge request branch, consider building KiCad with the flag CMAKE_BUILD_TYPE=Debug, so that you can run an interactive debugger, e.g. using QtCreator. To compile with QtCreator's IDE (but still using native CMake and gdb), just click on File, Open File or Project, CMakeLists.txt
I’m trying to keep the pages self-sufficient enough but still minimal, focusing only on Linux and especially different distros, so I’ll leave IDEs out. But I added more info about flags to the generic page (RelWithDebInfo is recommended in the official instructions).
Python3 has been mandatory for some time and no build flags are needed for that. OCC is now the default and shouldn’t need any attention. The instructions reflect this.
I have also added some details to the generic page. There’s some feature creep, but this should now cover most of the wanted build time options (installation path, using clang and ninja…) so that both a novice and a more experienced user can do what they want without reading other documentation or trying to debug build problems.
Any idea whether the instructions in your wiki might work for Kicad5 on debian buster ?
$ python --version
Python 2.7.16
$ python3 --version
Python 3.7.3
The main point in the instructions is that if you have some KiCad version available in some repository, you surely can build that same version with the same options as the package has been built with. I didn’t succeed with the combination 5.99 and python3/phoenix, but if you can enable a source repo which has version 5.1, you can install the build dependencies and try compiling it.
That said, I understand that it’s a relatively easy way to ensure the build environment is setup correctly, so maybe that makes sense for people getting started with doing their own builds. It’s just not the way I would do it.