question(developer): do we remove kmcomp.exe entirely in 17.0? 🗜

[mcdurdin]

This is a discussion issue around the pros/cons of removing kmcomp.exe and kmcmpdll.dll entirely from 17.0, forcing a move to kmc throughout.

In order to do this we still need to:

1. Complete the kmc-kmn/kmw-compiler fixes
2. Add support for keyboard_info merge
3. Move tike.exe integration to using kmc instead of kmcmpdll
4. Update keyboard repository build scripts to use kmc

Pros

• one codebase to maintain
• one less Windows dependency
• forces us to make sure kmc does everything in 17.0, rather than letting some edge cases drift to 18.0
• your pros here

Cons

• keyboard developer may encounter bug in kmc, forced to move back to KMDev 16.0 to continue work
• your cons here

Scenarios

• kmcomp wrapper interface for kmc? Does this make sense to write?
  • pro: pathway for existing users
  • pro: lets user do changeover on their timetable
  • con: More to maintain
  • con: delays the changeover to kmc
• think through handling regressions, etc.

[mcdurdin]

@LornaSIL notes that kmdecomp is still needed. Question: do we include it as part of kmdev17 or just a legacy separate download (legacy separate download may allow us to remove a number of legacy files from the source tree, but may be worth moving those into the kmdecomp folder?)

[mcdurdin]

Suggest turning kmcomp.exe into a stub program that prints help on how to migrate to kmc, with link to full migration guide.