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
command IDs.
Wayne
Dick
For
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".
Wayne
