kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #13406
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