kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Wed, May 21, 2014 at 10:15:16PM +0300, Gabriel Koutilellis wrote:
> Please let me know some basic environment that I can use to easily
> combine all the needed tools to develop something useful.

My personal opinions, other devs please add if I missed something

I'd say from start:
- Platform of choice (win, linux, macosx). Can't say much for macosx
  o win... AFAIK for win mingw is the supported build environment, for
  macosx there is a parallel subgroup of devs or something like that (on
  this list anyway)
- A decent development machine, C++ is slow to compile (especially when
  optimizing). When touching files under include a big coffee could be
  useful; disk should be plenty too: a full debug work directory under
  linux is about 5 GB on my box, and probably you would like to keep two
  of them
- Your preferred editor (notepad is *not* an editor :D); it *must* support
  UTF-8 encoded files, otherwise you will have troubles (it happened in
  the past)
- Recent gcc/g++ (at least >4.8, I'd say)
- gdb for stack traces and/or debugging (depending on your style); debug
  wx gives some stack trace but in my experience is not very accurate;
- bzr for pulling changes and stuff
- cmake (a recent one should be fine)
- wxWidget (I'd say to use 3.0), wxPython if you want to play with
  pcbnew scripting (I don't remember if these days works properly or
  segfaults, however)
- Debug builds of wx/GTK could be useful in some cases but I don't
  recommend to use them 'just because' (not trivial performance
  implications and compatibility issues)
- wxFormBuilder if you want to do dialogs/GUI work
- doxygen if you like html class browsing (I personally don't, YMMV)
- boost is not necessary since kicad pulls up its own copy anyway (there
  is some magic to be done for coroutines IIRC)
  
That should be a nice environment for doing work.

Also:
- Read the roadmap and start with something simple
- Read the coding guidelines
- Keep two different working directories for the code, one with stock
  (pristine) and the other with your branch/work in progress, so you can
  check easily if you broke something or if it was broke before:P IIRC there
  was some documentation about the suggested bzr workflow somewhere...
- Ask on the mailing list for guidance, obviously
- Remember than kicad has a C ancestry so not everything is 'pretty'
  C++: for example many core structures are intrusive dlists instead of
  being stuffed in STL containers; some things are suboptimal simply
  because they 'work good enough', of course improvents are accepted

Last but not least:

- Don't make Dick or any of the core developers angry :D

-- 
Lorenzo Marcantonio
Logos Srl