qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.08k stars 38.87k forks source link

Subproject_default: intended usage? #1093

Closed TerryMathews closed 6 years ago

TerryMathews commented 7 years ago

@jackhumbert Looking at the current source, there are 4 projects using SUBPROJECT_DEFAULT to force make to only make one subproject absent an argument:

Clueboard Ergodox Planck Kinesis

To me, one defining difference between these projects and other boards that QMK supports is that there really isn't much variation in how those projects are built. There might be keymap differences, but switch location is pretty much universal.

1070 merged in SUBPROJECT_DEFAULT=rev2 on Let's Split. There two ways to build a rev2: identically, or one half built "upside-down". There are advantages for both.

Identical orientation allows for different keymaps on each half so that you can change keymaps by changing which side is plugged in to USB. Same trick some people use with Ergodox. Flipped half orientation allows for the TRRS jacks to be on the inside edge and make the cabling look cleaner.

Part of the reason I did the maintenance I did on the Let's Split project was that I had trouble getting mine to work, and there were posters on Reddit that were having the same issues I was having. I have helped people who built their Let's Split like I did and both halves were identical.

All of this to say: Should we be picking a "default" on every project? I know there aren't many projects using the subproject feature at this point, which I think makes it all the more important for you to lay out your intent now. If I go into a project and just "make", should I be getting every variation or only the normal variation?

My $0.02 is that we should be building all unless there's a specific reason to exclude the other variations. QMK doesn't take long to compile on even a decade-old machine. It's user friendly and CPU expensive to default to all. I think most of us can easily afford the CPU expense.

jackhumbert commented 7 years ago

In general, default subprojects exist to keep the project "up-to-date", since new-comers are most likely to have the most recent hardware, but also allow different hardware configurations (eg ez vs infinity). With the both cases, it's strictly a numbers game - we wanna make it easiest for the largest group of people.

For the Let's Split, I think having a default subproject (rev2 for now) is fine, as long as it's clear what that is, and how the alternative compares, and how to compile with it (make lets_split-rev2fliphalf).

I would advise against compiling all subprojects - in an environment where you're making many modifications and testing them out, waiting to compile unneeded files shouldn't have to be tolerated :)

Avispa commented 7 years ago

If I put SUBPROJECT_DEFAULT = infinity into my key maps local Makefile and run make it still keeps building EZ instead. If I copy and paste it as argument to make (just to get sure not having a typo) it builds the infinity layout as expected.

Did I found a bug or do I just do some wrong?

Avispa commented 7 years ago

Okay, was to obvious and a bit silly of me. Sorted it out myself. ;)

For others who are wondering: just set SUBPROJECT = infinity in your Makefile.

TerryMathews commented 7 years ago

Intended usage is make infinity

On Jun 8, 2017 9:28 PM, "Avispa" notifications@github.com wrote:

If I put SUBPROJECT_DEFAULT = infinity into my keymaps local Makefile and run make it still keeps building EZ instead. If I copy and paste it as arguement to make (just to get sure not having a typo) it builds the infinity layout as expected.

Did I found a bug or do I just do some wrong?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/qmk/qmk_firmware/issues/1093#issuecomment-307270345, or mute the thread https://github.com/notifications/unsubscribe-auth/AB4VBS7_ybmHt_ZMQD7_KSXio5mpi98wks5sCJ--gaJpZM4L-yM2 .