← Back to team overview

kicad-developers team mailing list archive

Re: Environment for development

 

Thank you very much.
I hope that soon I shall be able to help the community.

G


On Wed, May 21, 2014 at 10:56 PM, Lorenzo Marcantonio <
l.marcantonio@xxxxxxxxxxxx> wrote:

> 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
>
> _______________________________________________
> 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
>

References