Closed fredizzimo closed 8 years ago
Ah, I can see that Travis-CI support is already partly there https://github.com/jackhumbert/qmk_firmware/pull/374.
But I still would like to see it controlled by a script instead, so it can be run locally as well.
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).
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.
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.
Moved the makefile stuff to #385 :)
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.
I added these to the core Makefile chain here. It's currently required that all keymaps have a Makefile.
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!
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
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.