Multiple .bin/.hex files in build directory

[bridadan]

At the moment, Nordic targets create <module-name>.bin, <module-name>.hex, and <module-name>-combined.hex files in the /build/<target>/source directory.

For new users (and careless experienced users!) it is not clear which file can/should be flashed to the device. However, I understand the need for creating all of these files.

Would it make sense to move the non-drag-and-drop-ready binaries/hex files to a sub folder? For instance, /build/<target>/source/bin or /build/<target>/source/intermediate or /build/<target>/source/tmp ?

[rgrover]

I understand that it may not be clear which build artifact to use for programming the target; but in that case the normal thing to do would be to read documentation. Should the problem be solved by making documentation more accessible? https://github.com/armmbed/ble-examples#building-and-testing-the-examples

[bearsh]

what I am wondering, why are these file in /source at all? why not habe a /build/<target>/{out, bin, hex, what ever} folder?

[bridadan]

@rgrover In the ideal situation, yes. But even after reading the documentation its easy to make the mistake without realizing it. I'd rather we expose the drag-and-drop-ready .hex in the /build/<target>/source folder by default (since that is the default behavior for other mbed platforms) and move the other artifacts to a subfolder. These artifacts should be well documented in the documentation for sure.

@bearsh I've asked myself that question too :) It does seem kind of funny, but I think the idea is in your module.json, there's the field "bin": "./source" which is telling yotta this is an executable. So your "bin" is created in the same folder that you specify in your module.json.

Though to be honest, I think having a /build/<target>/bin or some other folder makes quite a bit of sense. It definitely is more consistent with existing workflows. cc @autopulated thoughts?

[autopulated]

Yeah they're in the source directory under build because it's the contents of the source directory that are being built into the executable. It's technically possible to have multiple directories building into separate applications.

FWIW I think you could change this by adding (untested):

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/../bin")

in a something.cmake file in your source folder, but it's possible that this will confuse other tooling.

[rgrover]

@bridadan: can we really be sure that one of the artifacts is more important than the others to the extent that the rest should be put away into a subfolder? Can we also be sure that our attempts to document this new organization will help users locate/discover the subfolder containing the other artifacts, given (as you say) than reading documentation doesn't always work? Are we trying to impose some kind of order upon some more fundamental disorder? And is the suggested cure any significantly better than the disease for most people?

I believe the problem you are trying to solve applies only to first-time (or infrequent) users. If it is more of the former, then we may assume that first-time users tend to refer to documentation. If you have something to substantiate the argument that this is a significant and repeating problem, then we will address it.

How does @jaustin feel about it? @pan-?

[pan-]

I do not like the idea of segregating generated binary files. All the files generated are important moving some of them which are not considered important for some might be counter productive.

For instance the elf file generated is really important for debug purposes, the file .bin is very important for software upgrade, ... The user should understand what he is doing. Hiding "complexity" might help the first steps but it make "advanced" usage more complicated than before. I do not think that this is desirable.

[ghost]

I was used to this behaviour from learning from @rgrover's Makefile code for offline mbed usage, but it is a bit confusing out of the box for new folks.

Is there any way that some some helpful info could show up after yt build ?

[bridadan]

I think some info after a yt build would be helpful. Maybe something like this?

Built applications:
<module-name>              - ELF file containing debug symbols
<module-name>.bin/hex      - Application only (no SoftDevice), suitable for FOTA
<module-name>-combined.hex - Application and SoftDevice, suitable for flashing/drag and drop

[BlackstoneEngineering]

I second @bridadan 's idea, I am seeing heaploads of trouble in China / Asia where english is not their first language, they are flashing whichever .bin / .hex is highest in their file browsers and assuming it will work, having the extra files there that should not be flashed only serves to cause confusion and problems for the end user.

Ideally we should not provide extra files in the build output directory, or hide them behind theyt build -d flag so they only show up when debugging. Lacking that more intuitive UI then providing more verbose information as @bridadan suggested above will work as well.