portapack-mayhem / mayhem-firmware

Custom firmware for the HackRF+PortaPack H1/H2
GNU General Public License v3.0
3.02k stars 518 forks source link

add real gcc ver chk #2118

Closed zxkmm closed 2 months ago

zxkmm commented 2 months ago

it's because it happend on me and gull that the current check gcc ver isn't that reliable. This is read from elf target which were compiled, which should be accurate

NOTE that i'm not sure if this will break pipeline. i need to check on my fork HOWEVER even after it passed from my side it's still need a nightly release to check work

readelf cmd is from binutils. which idk if it's included in pipeline. (edit: pipeline compile passed)

https://github.com/zxkmm/mayhem-firmware/actions/runs/8778357213

u-foka commented 2 months ago

Doh, sry totally forgot about this :/

This is nice to be able to tell about any binary what exact version it was built with :)

To fix the detection issue in cmake however it is potentially enough to replace "arm-none-eabi-g++ -v" with "${CMAKE_CXX_COMPILER} -v" (havent tested this yet :))

Will send that as a separate PR, this I'll try to read in the evening it should go in regardless 👍

Brumi-2021 commented 2 months ago

Hi , I think that @NotherNgineer , already merged another PR that writes in the user settings the used gcc version to create that binary . Is that the same issue 🤔?

zxkmm commented 2 months ago

Hi , I think that @NotherNgineer , already merged another PR that writes in the user settings the used gcc version to create that binary . Is that the same issue 🤔?

No. It’s somehow not accurate.

NotherNgineer commented 2 months ago

It would be better if there was a single message versus one per ELF file -- because now the percentage ROM utilization scrolls off the screen.

zxkmm commented 2 months ago

It would be better if there was a single message versus one per ELF file -- because now the percentage ROM utilization scrolls off the screen.

Thanks! I'll submit with a new PR with compare.

zxkmm commented 2 months ago

After thinking, I think it's not quite make sense to compress the output, since it could be possible if ccache mistakenly skipped compiling in some edge case that we didn't know, and it's would be harder to debug.

and about flushing the screen, I think other things do that as well, for example cmake itself:

[ 64%] Built target baseband_gps_sim.elf
[ 66%] Built target baseband_test.elf
[ 70%] Built target baseband_audio_beep.elf
[ 70%] Built target baseband_spectrum_painter.elf
[ 73%] Built target hackrf_usb_objects
[ 77%] Built target hackrf_usb_ram_objects
[ 80%] Built target hackrf_usb_dfu_objects
[ 97%] Built target application.elf
[ 97%] Built target hackrf_usb.elf
[ 97%] Built target hackrf_usb_ram.elf
[ 97%] Built target hackrf_usb_dfu.elf
[ 97%] Built target application
[ 97%] Built target hackrf_usb_ram.bin
[ 97%] Built target hackrf_usb.bin
[ 97%] Built target hackrf_usb_dfu.bin
[100%] Built target baseband

SO i added a new PR just simply tuned the print order. This we can see the % in last screen.