Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global make shell script and Travis-CI #382

Closed
fredizzimo opened this issue Jun 5, 2016 · 8 comments
Closed

Global make shell script and Travis-CI #382

fredizzimo opened this issue Jun 5, 2016 · 8 comments

Comments

@fredizzimo
Copy link
Contributor

One thing that would help me enormously when implementing the ChibiOS support, and doing refactoring, would be to have a generic make file or shell script, which would build everything.

The Ergodox EZ keyboard already contains a such script, makeall.sh, but what's missing is one that starts from the root and does a similar thing for the whole repository. It also doesn't need to build the hex files, just compiling and linking the target is enough.

The Ergodox script also doesn't handle the case where a custom make file is used, and some defines are changed for example. In that case a clean would be needed, for a proper compile. That is of course very unfortunate as cleaning between each keyboard and keymap would take a lot of time. Fortunately there's an easy optimization, so the process would look like this

For each keyboard

  1. Clean
  2. For each keymap without it's own make file
    1. make
  3. For each keymap with it's own make file
    1. Clean
    2. Make

This could further be extended with Travis-CI support, so that everything is checked for all pull requests. Of course it doesn't guarantee anything, but at least it makes sure things compiles.

I will implement a such script now and send a pull request when done. The travis-ci support will have to be left for later though.

@fredizzimo
Copy link
Contributor Author

Ah, I can see that Travis-CI support is already partly there #374.

But I still would like to see it controlled by a script instead, so it can be run locally as well.

@jackhumbert
Copy link
Member

jackhumbert commented Jun 5, 2016

Yeah! I was thinking something similar after #374. This is my first time messing with travis-ci, but can't it just run the script?

We could make a special make target that just compiles and links, right? I'm not sure that would save a whole lot of time, but I think it's just the %.elf target in rules.mk

One thing I would like to be able to do is compile directly from the keymap/<layout> folder, and output the .hex there (much like the ez's structure already is).

@fredizzimo
Copy link
Contributor Author

I'm not very familiar with Travis either, but yes it should be possible to call the script from there.

If the target that just compiles and links is not there, it's probably not worth it. But if it can be called, then I think it could be used. It would probably not save a lot of time, but I was thinking more about the move part of the makeall.sh script, which modifies the hex file in the repository and shouldn't be called unless really requested.

I think compiling directly from the keymap folder is separate issue. But it would probably need some kind of restructuring of the make files, or perhaps more easily by having a some kind of script that does it. I believe the script can be a generic one that determines the keymap name based on the current directory, then goes up one directory to build it, and returns to the keymap folder afterwards. This file could be in the path, so it doesn't need to be duplicated for all the keymaps.

@jackhumbert
Copy link
Member

Yeah, I agree, but my logic there is that if we can force the Makefile to exist in/move it to the keymaps/<layout> folder, we can just call make from all of the keymaps folders, rather than making a conditional to test if the makefile exists. I know it's kind of a trivial thing to avoid, but it'd divert our stone to hit another bird :) it'd also significantly reduce the size of the makefile, since half of it is doing the keymap checking/including. The keyboard-specific options can then be pulled out to the keyboard's makefile, which would get included by the keymap's.

@jackhumbert
Copy link
Member

Moved the makefile stuff to #385 :)

@jackhumbert
Copy link
Member

jackhumbert commented Jun 6, 2016

I don't know if you've started this yet, but I started messing around with a colored output makefile to do this at 6199f52 - right now it just does Plancks, but can be configured to do all of them like this:

index 2cfa496..356db55 100644
--- a/all.mk
+++ b/all.mk
@@ -18,7 +18,7 @@ PRINT_OK = printf "$@ $(OK_STRING)\n" | $(AWK_CMD)
 BUILD_CMD = 


-SUBDIRS := $(sort $(dir $(wildcard keyboard/planck/keymaps/*/.)))
+SUBDIRS := $(sort $(dir $(wildcard keyboard/*/keymaps/*/.)))
 # $(error $(SUBDIRS))

 all: $(SUBDIRS)

It assumes all keymaps have a Makefile.

@jackhumbert
Copy link
Member

I added these to the core Makefile chain here. It's currently required that all keymaps have a Makefile.

@jackhumbert
Copy link
Member

I believe this has been fully implemented via #395 :) thanks for getting the ball rolling on this, and let me know if I missed anything!

BlueTufa pushed a commit to BlueTufa/qmk_firmware that referenced this issue Aug 6, 2021
* Make content keys selectable

 - this enables keyboard input, making it consistent with other keys we
   support. This should enable LT and all MT variants we support

* comments

* Simplify
KarlK90 added a commit to KarlK90/qmk_firmware that referenced this issue Nov 28, 2023
This contains commit from da78eb3759b8..9d7a7f904ed1:

    9d7a7f90 Merge pull request qmk#382 from KarlK90/fix/rp2040-i2c-speeds
    70119934 Merge pull request qmk#383 from
             KarlK90/fix/rp2040-usb-get-status-request
    1a1bbe6c rp2040: usb: fix usb_lld_get_status functions
    7d9212dd rp2040: i2c: fix speed calculation
    fb67e502 Merge pull request qmk#377 from 1Conan/sn32_fix_registry
    e72939ef SN32: update registry
    5b4836ca Merge pull request qmk#376 from dexter93/sn32_usb_v2
    5ded9de9 sn32: usb: do NOT clear interrupt status until handled
    Leftover Sonix reference code cleanup. Sometimes when there is
    traffic on more than 1 ep's packets would be dropped before they
    could be handled. Clearing the status flags after handling them
    takes care of it.
    e9a4a512 sn32: usb: only activate interrupts on lld start
    e4a35d1c sn32: fix host remote wakeup
KarlK90 added a commit that referenced this issue Nov 29, 2023
This contains commit from da78eb3759b8..9d7a7f904ed1:

    9d7a7f90 Merge pull request #382 from KarlK90/fix/rp2040-i2c-speeds
    70119934 Merge pull request #383 from
             KarlK90/fix/rp2040-usb-get-status-request
    1a1bbe6c rp2040: usb: fix usb_lld_get_status functions
    7d9212dd rp2040: i2c: fix speed calculation
    fb67e502 Merge pull request #377 from 1Conan/sn32_fix_registry
    e72939ef SN32: update registry
    5b4836ca Merge pull request #376 from dexter93/sn32_usb_v2
    5ded9de9 sn32: usb: do NOT clear interrupt status until handled
    Leftover Sonix reference code cleanup. Sometimes when there is
    traffic on more than 1 ep's packets would be dropped before they
    could be handled. Clearing the status flags after handling them
    takes care of it.
    e9a4a512 sn32: usb: only activate interrupts on lld start
    e4a35d1c sn32: fix host remote wakeup
EKlaman pushed a commit to EKlaman/qmk_firmware that referenced this issue Feb 6, 2024
alycklama pushed a commit to alycklama/qmk_firmware that referenced this issue Apr 9, 2024
nuess0r pushed a commit to nuess0r/qmk_firmware that referenced this issue Sep 8, 2024
This contains commit from da78eb3759b8..9d7a7f904ed1:

    9d7a7f90 Merge pull request qmk#382 from KarlK90/fix/rp2040-i2c-speeds
    70119934 Merge pull request qmk#383 from
             KarlK90/fix/rp2040-usb-get-status-request
    1a1bbe6c rp2040: usb: fix usb_lld_get_status functions
    7d9212dd rp2040: i2c: fix speed calculation
    fb67e502 Merge pull request qmk#377 from 1Conan/sn32_fix_registry
    e72939ef SN32: update registry
    5b4836ca Merge pull request qmk#376 from dexter93/sn32_usb_v2
    5ded9de9 sn32: usb: do NOT clear interrupt status until handled
    Leftover Sonix reference code cleanup. Sometimes when there is
    traffic on more than 1 ep's packets would be dropped before they
    could be handled. Clearing the status flags after handling them
    takes care of it.
    e9a4a512 sn32: usb: only activate interrupts on lld start
    e4a35d1c sn32: fix host remote wakeup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants