KiCad

Kicad as CMake subdirectory

Asked by Michał Chodzikiewicz

Hi all!

I'd like to know if you have ever tried to build KiCad with CMake not as top level project but as subdirectory - as far as I can see, there are plenty of ${CMAKE_CURRENT_SOURCE_DIR} references that breaks as soon as you add into your project:

------------------

cmake_minimum_required(VERSION 3.13)
project(kicad-auto)

add_subdirectory(kicad)

--------------------

It is a pitty... I'd love to use its code to build custom wrappers (and for example solve lack of command line ERC/DRC/output files generation to use with CI)

I am willing to spend some time on fixing all these references and push it upstream, but I'd like to know if there is a will to pull this kind of change - I'd like to avoid maintaining a fork of KiCad that is containing only cmake refactor...

BTW - I am hugely dissapointed by the current state of CLI - I have blindly assumed that if this is a community project, such an API exists - It is major selling point for me over other EDAs

Question information

Language:
English Edit question
Status:
Answered
For:
KiCad Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Wayne Stambaugh (stambaughw) said : 		#1

You have several questions so hopefully I can answer them for you.

AFAIK, our CMake files are not designed to build KiCad as a sub-project. It is designed as a stand alone application. That being said, I would not be opposed to patching our CMake files to allow KiCad to be built as a sub-project as long as the changes do not break the normal build of KiCad. You are the first person I can remember requesting this so if you are up for it, give it go.

I am not sure what you are referring to by CLI. Do you mean running KiCad without a UI or do you mean a interface in the UI that will allow you to enter commands to create entities in the editors. Both have been discussed many times but have not been a high enough priority to commit developer resources to implement. Once again, if you are feeling up to the task and have the time, skill set, and patience to wade through the KiCad code base to implement these features, the KiCad project would be more than happy to collaborate with you on that. FYI, most of our users who are CLI gurus use our Python scripting module to automate board editor tasks. A Python module for the schematic editor is planned for the next stable release of KiCad.

Revision history for this message
Michał Chodzikiewicz (mchodzikiewicz) said : 		#2

Thank you for an answer!

Regarding the first one - I think I have already done this by substituting CMAKE_SOURCE_DIR with KICAD_SOURCE_DIR and assigning CMAKE_CURRENT_SOURCE_DIR in top level CMakeLists.txt. Where can I push the changes? Is there a script / CI environment that could verify if my changes doesn't break any build configuration? (make all on my system works just fine)

Regarding the second point - I have read about python wrapper for pcbnew and 6.0.0 roadmap, what I am reffering to is at this point ability to run KiCAD without GUI to perform ERC, DRC and generate gerbers, drill, BOM and CPL - this would allow an organization to setup continuous integration environment for their hardware projects. It would be nice to be able to perform it without any additional tooling (for example python) by running something as simple as

pcbnew --drc-report board.kicad_pcb
pcbnew --plot board.kicad_pcb ../Outputs

eeschema --generate bom --generate cpl

etc

I thought that such an option is missing because for example you have some design considerations in mind for the future release - if such a contribution is welcome, I can try to do this in the main repository instead of wrapping it (however - ability to use kicad as a subproject is still a valid feature for some more specific needs)

Revision history for this message
Wayne Stambaugh (stambaughw) said : 		#3

I don't think the CI environment is the final word. You still have to be able to install everything properly so you need to validate that `make install` still installs everything in the correct paths. If want this considered for merge into KiCad, please use `git format-patch` and send the patch to the developers list for review and comment.

We are currently not working on any CLI changes at the moment that I am aware of. You may find that running KiCad without a UI may not be possible. I have never tried it. You could use the shared object (_kiface) and create a separate command line interface but I'm not sure this would get you everything you need or would even be desirable. I'm not sure I'm comfortable with multiple KiCad executables just to implement a CLI.

Can you help with this problem?

Provide an answer of your own, or ask Michał Chodzikiewicz for more information if necessary.

To post a message you must log in.