kicad-developers team mailing list archive
Mailing list archive
Re: Command ID refactoring.
Dick Hollenbeck <dick@...>
Tue, 22 Sep 2009 13:43:08 -0500
Thunderbird 188.8.131.52 (X11/20090817)
Wayne Stambaugh wrote:
Another way that I side step having to recompile more than what I am
working on is to simply build a subset of the targets.
Dick Hollenbeck wrote:
Wayne Stambaugh wrote:
I just want to make everyone aware of the command ID refactoring commit
I just made. I separated the application specific command IDs in
"include/id.h" to separate files in each application (kicad, cvpcb,
gerbview, etc.). The only IDs remaining in "id.h" are common to
multiple applications. This prevents the entire project from being
rebuilt when adding a new command ID to any single application.
Did you actually test this "compile avoidance assumption" ?
Yes. You can try it out by opening "pcbnew_id.h" and adding a new
command ID to the end of the list and rebuilding the project. None of
files in any of the other applications will be recompiled. Only the
files in PCBNew that include "pcbnew_id.h" will be built. If you add an
ID to "include/id.h", every project file (which is most of them) that
includes the local command ID file will get rebuilt. The local command
IDs are enumerated from the end of the global command IDs so there
should be no duplicate command IDs within each application. I also
created a few new command IDs because there was some strange command ID
usage. I found some LIBEDIT command IDs in PCBNew. I'm sure someone
probably meant to use MODEDIT instead.
Because sometimes just header file nesting can break this independence.
There is plenty of this in the project as well. I typically try to
check every source file that I edit for unnecessary header files.
(IMO, unless the goal is actually achieved, I would not prefer the split.)
Personally I always liked using ::wxNewID() instead of static ID
definitions. I always figured that this method was less likely to
result duplicate command IDs and I don't have to manually keep track of
future reference, please put application specific IDs in the appropriate
header file ( "pcbnew_id.h" for PCBNew command IDs ). Only command IDs
shared across more than on application should be put in "include/id.h".
from debug/pcbnew only builds pcbnew
$ make help
tells me what I can build from within debug/pcbnew
some of the *.i or *.o targets can be helpful to simply get rid of a
single file compilation problem.
$ make pcbnew
from the debug directory is what I mostly use when developing.
And then I can run it from there with: