Do we need to litter the working directories with .hex files?

[fredizzimo]

I'm slightly annoyed by the fact that the build system output .hex files in the same directory as you run the make. It makes it hard to navigate the file system and see the important things.

In addition to that they can already be found in the .build folder, but since that folder is hidden, maybe the should go to something like /firmware? I chose the name firmware instead of hex, because some keyboards need bin files instead.

Also, in most cases the user don't need to care about the files at all, since the make command does everything.

[jasonm23]

so rm *.hex

[jackhumbert]

@jasonm23, @fredizzimo's sentiments are shared by myself and others, and there are other .hex files that would need to be protected from an rm *.hex.

@fredizzimo I've been debating moving the .build folder to build to make it a little more accessible. We could then do away with copying it to the target folder, unless specified via a flag. There would still be the problem of it being in every subfolder, but it'd be a little more organised.

[fredizzimo]

@jasonm23, Is there a reason why you would want to keep them in the same directory as you run make from? If there are then please tell, because finding out was the reason why I opened an issue rather than do the required quick fix and submit a pull request.

And by litter, I really mean that

$ find . -name "*.hex" | wc -l
818

For normal users that just compile single keyboards this is not a problem, but when you have to try out many of them it starts to be a problem. My numbers are inflated though, as I still have the old .build folders left, which are no longer created as explained below.

@jackhumbert I think renaming it to build is a good idea. And actually the build folder is no longer created everywhere, Pull request #596 removed that, well actually #595 did, but that was included in #596. The reason for that chance was a technical one, and it had been mentioned in #591 as one of the things to do anyway, so I changed it immediately instead of trying to fix the issue that was caused by having them all around the place.

That said, we could still have some kind of output in other directories as well. But then maybe a firmware folder that contains just the hex and/or bin files would be better. Another option would be to always output the firmware files to the keymap directories. Then at least there wouldn't be a huge number of extra files, mostly a handful for keyboards with a lot of subprojects.

[jasonm23]

Hi, I figured the use case where there are many .hex files was very rare. As a more helpful suggestion than `rm *.hex`, I think a `make` target that selectively cleans up .hex files for a named keyboard would be more useful than changing the default behavior, since neophyte users may get lost trying to find a .hex that isn't in the folder. My feeling is anyone sufficiently experienced to have an issue, (i.e. Making too many .hex files.) is also adequately prepared to clean up too. Giving this class of use a helper target is what I would do.

[jackhumbert]

@fredizzimo ah, right! Yeah, I think outputting the .hex to the keymap folder probably makes the most sense for organisation, especially since the .build folder doesn't exist in the current folder anyway :)

I think it'd be sufficient to just put the .hex files (optionally .bin files, if specified in the Makefile) in the keymap folders, without a firmware folder - the name "firmware" may be a little confusing too, since both the keymap and the .hex files are both "firmware."

[fredizzimo]

This was fixed a long time ago.