Conversation
|
One thing I noticed was that I intended that we should put the definitions of However I also realized now that |
|
Also just redefinig the |
|
we could also have a separate |
The |
+1 |
That makes sense to me in case it reduces the built object files. |
Makes sense - I'll open a separate request for this. |
conte91
force-pushed
the
cmake_cleanup_stage1
branch
3 times, most recently
from
80d1276 to
7c36a20
Compare
Codecov Report
@@ Coverage Diff @@
## master #247 +/- ##
==========================================
- Coverage 41.66% 41.44% -0.22%
==========================================
Files 96 94 -2
Lines 5439 5407 -32
==========================================
- Hits 2266 2241 -25
+ Misses 3173 3166 -7
Continue to review full report at Codecov.
|
conte91
force-pushed
the
cmake_cleanup_stage1
branch
from
7c36a20 to
635cf8f
Compare
NickeZ
left a comment
NickeZ
left a comment
There was a problem hiding this comment.
overall looks good to me. Remember that we must double check that the usb descriptors stay the same and that the btconly firmware doesn't have any u2f/eth symbols in it.
| target_link_libraries(${elf} PRIVATE c asf4-drivers-min -Wl,-u,exception_table) | ||
| add_dependencies(${elf} libwally-core) | ||
| add_dependencies(${elf} noise-c) | ||
| target_link_libraries(${elf} PRIVATE c asf4-drivers-min noiseprotocol -Wl,-u,exception_table) |
There was a problem hiding this comment.
I think noise and libwally shouldn't be needed in the bootloader.
There was a problem hiding this comment.
Fixed. There was a missing dependency between libwally.a and libwally-core (the target actually building libwally!), so the dep tree was broken.
| target_sources(${elf} PRIVATE ${BITBOX02-FIRMWARE-SOURCES}) | ||
| else() | ||
| target_sources(${elf} PRIVATE ${BITBOXBASE-FIRMWARE-SOURCES}) | ||
| endif() |
There was a problem hiding this comment.
I don't think this pattern (find string in elf name) works well here. It works well for the "semhosting" string because it is binary. I think it would be better if you created two variables: "FIRMWARES-BITBOX02" and "FIRMWARE-BITBOXBASE" a bit like there is for the bootloaders. Then you could iterate only over the bb02 firmwares or the bbb firmwares and add sources.
conte91
force-pushed
the
cmake_cleanup_stage1
branch
4 times, most recently
from
8ae0f80 to
b20204b
Compare
conte91
force-pushed
the
cmake_cleanup_stage1
branch
from
b20204b to
a9710c9
Compare
| @@ -0,0 +1,385 @@ | |||
| // Copyright 2019 Shift Cryptosecurity AG | |||
There was a problem hiding this comment.
this file is nowhere to be found in cmakelists.txt, how does that work?
| #endif | ||
|
|
||
| #include "gestures.h" | ||
| #if PLATFORM_BITBOXBASE == 1 |
There was a problem hiding this comment.
is this redundant? hopefully this file would only be compiled for bitboxbase only.
| #include "gestures.h" | ||
| #include "gestures_impl.h" | ||
| #if PLATFORM_BITBOXBASE == 1 | ||
| #include "gestures_bitboxbase.h" |
There was a problem hiding this comment.
what's the difference to gestures_bitboxbase.c?
As the files related to APP_BTC don't depend on any PRODUCT* macro, but only on the APP_* macros, move those to a separate CMake unit (app_btc-multi, app_btc-btc), to avoid multiple unnecessary compilations.
Most of the workflow, components, and UI code doesn't depend on the platform it will be run on. Compile it only once to save many CMake build entries. The gestures code is a dependency of most components, but it has a slight dependency on the hardware platform. Split it into an API and an implementation file to let including the header possible without having to define the platform the code will run on.
conte91
force-pushed
the
cmake_cleanup_stage1
branch
from
a9710c9 to
c6b3b40
Compare
4 participants
Trying to recover from the multitude of added compilations that the BitBoxBase firmware introduced. This PR adds modularization to the code, and tries to bulid with as little
PRODUCT_*,APP_*etc. definitions as possible. In order to make sure that nothing breaks whenundefining those macros, they are enforced to be#defined in the relevant headers (so if a code unit doesn't really need the macro, it won't be able to include the headers that depend on it).