Move keymap-specific Makefile options to keymaps somehow

[jackhumbert]

No description provided.

[jackhumbert]

Action in the Makefile that scans the keymap being compiled for a USING_UNICODE, and overwrites the option in the Makefile?

[ezuk]

I don't love scanning like this because it might get triggered by mistake or something. Thinking about how we might integrate this with Fusion, how about we go with a -f as described in the Make docs?

So for example, if I wanted to specify a custom make file for keymap_oscar, I'd call it make_keymap_oscar, stick it right alongside the firmware, and in the README for that keymap (which I try to get everyone to include before I merge their keymaps in), I'd specify how to invoke make with it.

What do you think?

[jackhumbert]

We could do that, and have the custom Makefile include the common one - we'd need to stick some if statements in the common Makefile to accommodate that.

But I'm imagining a first line comment similar to:

 # REQUIRES_UNICODE

That would make it pretty obvious to the user, and we could output some comments saying the current options have been overridden.

[jackhumbert]

This makes things a little more organised as well, keeping things all in one file. Honestly, I'd be interested in merging the readmes into the .c files.

[ezuk]

The reason I like the having the Readme.md alongside the keymap is how github renders it. I have a lot of people who aren't super comfortable with C look into the repo, and I want to make it easy for them to understand what each keymap does, and choose the one they want (that's also why I like it when people check in hex files).

So my ideal keymap goes something like:

• keymap_moo.c
• keymap_moo.png (image showing it, not a must of course)
• keymap_moo_README.md
• keymap_moo.hex

That's just for my own keyboard obviously, but I find that it helps people understand what they're getting without becoming confused. I'd rather have multiple files, each doing something specific, than one big file that tries to be both code and docs.

As for the makefile issue... Well, could go either way. I'm not so sure about the directives but if that's the direction you find more compelling, sure, let's do that. :)

[jackhumbert]

Got a working version up in the smarkefile branch :)

Right now, you can throw USING_UNICODE, USING_MIDI, or USING_BACKLIGHT anywhere in your keymap file, and it'll include the correct stuff/set the flags. I put it as a comment like this, but I'm open to ideas:

// USING_MIDI

What do you think about organising those keymaps in folders? That would allow github to display the README more easily. The structure could be:

• keymap_moo/ (or even moo/)
  • README.md
  • default.c
  • default.hex
  • default.png

That'd also allow folks to have alternative versions more easily. I haven't tested it, but we should be able to do make KEYMAP=keymap_moo/default without breaking anything.

[jackhumbert]

Testing this out here - I have a smart Makefile looking to see if <name>.c exists, and if it doesn't, it pulls <name>/default.c. If neither exists, it errors out.

[ezuk]

I love the idea of using a folder structure! Will try something out over the next few days. Left a comment on that commit re the file scanning (breaks cross-platform).

[jackhumbert]

Dang.. I guess that's where late-night coding gets me. There might be some better cross-platform tools available - I'll circle back around with this!