Initial restructure to support multiple target architectures #1675

mikee47 · 2019-04-25T16:55:42Z

As per discussion #1333.

Rearrange files and fix #includes:

Rename SmingCore -> Core
Rename SmingCore/Platform -> Platform
Rename system -> System
Move Services/libb64 -> Components
Move Services/WebHelpers -> Core/Network
Remove apptest
Move Esp8266-specific code:
- Move most Platform sources -> Arch/Esp8266/Platform
- Move some SmingCore sources -> Arch/Esp2866/Core
- Rename compiler -> Arch/Esp8266/Compiler
- Rename tools -> Arch/Esp8266/Tools
- Move SmingCore/Network/rBootHttpUpdate -> Arch/Esp2866/Core/Network
- Move custom_heap -> Arch/Esp8266/Components
- Move some of system files -> Arch/Esp8266/Components/esp8266 (reflects IDF layout)
- Rename appinit/user_main.cpp -> Arch/Esp8266/Components/esp8266/startup.cpp
- Rename gdb -> Arch/Esp8266/Components/gdbstub
- Rename appspecific/gdb -> Arch/Esp8266/Components/gdbstub/appcode
- Rename Services/FATFS -> Arch/Esp8266/Components/fatfs
- Move system/include/rboot-integration.h, appspecific/rboot/overrides.c -> Arch/Esp8266/Components/rboot/appcode
- Rename Services/SpifFS -> Arch/Esp8266/Components/spiffs
- Move include/user_config.h -> Arch/Esp8266/System/include

Makefile revisions

Remove Makefile-project.mk
Rename Makefile-rboot.mk -> Makefile-app.mk
Retain Makefile-rboot.mk (redirects to Makefile-app.mk) for backward compatibility
Separate common script used by both Sming and App
- build.mk contains host environment setup
- Add directory definitions ARCH_BASE, ARCH_SYS, ARCH_CORE, ARCH_COMPONENTS and ARCH_TOOLS
- modules.mk contains rule creation script
Separate-out ESP8266-specific script:
- Arch/*/build.mk included by build.mk file
- Arch/*/sming.mk included by Makefile
- Arch/*/app.mk included by Makefile-app.mk
Change build output directory to Arch/*/out
Pull related variable definitions and rules together
Define macros to replace repetitive script: endeavour to name files or directories once only
Ignore errors in all clean operations
Use TOOLS, TOOLS_CLEAN and CLEAN variables containing pre-requisites for tools, tools-clean and clean targets
Simplify user library building by adding to LIBS, each library gets an additional shorthand make target e.g. make axtls.
Distribute PHONY declarations
Add decode-stacktrack rule to application makefile
Add help target to extract formatted makefile comments
Add list-config target

Submodule handling

third-party libraries: rBoot, new-pwm, axtls-8266, umm_malloc, esp-open-lwip, lwip2 -> Arch/Esp8266/Components
Move .patch file into related submodule parent directory
Internal SDK moved into Components/Sdk and updated to use unpatched Version 3.0 release
Move remaining third-party submodules into Components
Revise Makefiles so that only those submodules required for a build are updated/patched and built
- Add SUBMODULES variable to specify which submodules are required
- Use .submodule file as consistent pre-requisite for update/patching of all submodules
- Make ARDUINO_LIBRARIES a public variable to optionally restrict which libraries get loaded and built
- Add submodules and submodules-clean rules to replace third-party and libraries rules

Other

Add building.md
Add help documentation to makefiles, with new help and list-config targets
Update coding style directories and Travis checks
Update Doxygen directories

Fixes:

Add libpwm_open to CUSTOM_TARGETS so it builds with framework

Bugs found:

Testing with ENABLE_CUSTOM_LWIP=0 fails because of static definitions in mem_manager.h - also happens with existing build

Rearrange files and fix #includes * `Platform` -> `Platform/Esp8266/Platform` * Create `Platform/Common` for shared headers and code * `custom_heap` -> `Platform/Esp8266/System/components/custom_heap` * `compiler` -> `Platform/Esp8266/Compiler` * `appspecific/ * `tools` -> `Platform/Esp8266/Tools` * Esp8266-specific modules from `SmingCore` -> `Platform/Esp2866/Core' * `SmingCore/Network/rBootHttpUpdate*` -> `Platform/Esp2866/Core/Network` * Fix gdb paths - use `gdb/` for always-build, `gdbstub/` for internal * Rename `system` directory to `System` Create Esp8266 system components and group with related submodules * Move Esp8266-specific files from `system` into `Platform/Esp8266/System/components/esp8266` * `appinit/user_main.cpp` -> `Platform/Esp8266/System/components/esp8266/startup.cpp` * `gdb` -> `Platform/Esp8266/System/components/gdbstub` * `appspecific/gdb` -> `Platform/Esp8266/System/components/gdbstub/appcode` * `Services/FATFS` -> `Platform/Esp8266/System/components/fatfs` * third-party libraries: `rBoot`, `new-pwm`, `axtls-8266`, `umm_malloc`, `esp-open-lwip`, `lwip2` * Move `.patch` file moved into submodule parent directory * `system/include/rboot-integration.h`, `appspecific/rboot/overrides.c` -> `Platform/Esp8266/System/components/rboot/appcode` * `Services/SpifFS` -> `Platform/Esp8266/System/components/spiffs` Makefile revisions * Remove `Makefile-project.mk` * Rename `Makefile-rboot.mk` -> `Makefile-app.mk`, but retain `Makefile-rboot.mk` for backward compatibility * Move common environment setup into `build.mk` and add platform-specific directory definitions * Move common target creation code into `modules.mk` * Put ESP8266-specific script into `Platform/Esp8266/` makefiles: `build.mk`, `sming.mk`, `app.mk` and `flash.mk` * Pull related variable definitions and rules together in makefiles * Define macros to replace repetitive script * Ignore errors in all clean operations * Use `TOOLS`, `TOOLS_CLEAN` and `CLEAN` variables containing pre-requisites for `tools`, `tools-clean` and `clean` targets * Remove `include` directory, move `user_config.h` into `Platform/$PLATFORM/System` folder * Distribute PHONY declarations * Add `PLATFORM_TOOLS` path, adjust locations for memanalyzer in host makefiles * Simplify user library building by adding to `LIBS`, each library gets an additional shorthand make target e.g. `make axtls`. * Add `SUBMODULES` variable to identify submodule directories - they're now not all in third-party directory * Use `.submodule` file to simplify reloading * Make `ARDUINO_LIBRARIES` a public variable to optionally restrict which libraries get loaded and built Add `building.md` Fixes: * Add `libpwm_open` to `CUSTOM_TARGETS` so it builds with framework Bugs found: * Testing with `ENABLE_CUSTOM_LWIP=0` fails because of static definitions in `mem_manager.h` - also happens with existing build

slaff · 2019-04-26T09:00:53Z

Platform -> Platform/Esp8266/Platform

Wouldn't it be better to rename it to Platform/Esp8266? Without one more Platform at the end.

custom_heap -> Platform/Esp8266/System/components/custom_heap

Why not Platform/Esp8266/Components/custom_heap ? Without the System part. The Components directory for every platform should be the place to store third-party libraries, components, etc. For example Platform/Esp8266/System/components/spiffs should be Platform/Esp8266/Components/spiffs

appinit/user_main.cpp -> Platform/Esp8266/System/components/esp8266/startup.cpp

Why not Platform/Esp8266/AppInit/startup.cpp ? This is shorter and should be one of the files that every platform must implement.

Move Esp8266-specific files from system into Platform/Esp8266/System/components/esp8266

How about Platform/Esp8266/System/ ?

gdb -> Platform/Esp8266/System/components/gdbstub

Also Platform/Esp8266/Components/gdbstub.

Bugs found:

Testing with ENABLE_CUSTOM_LWIP=0 fails because of static definitions in mem_manager.h - also happens with existing build

Interesting. I have double checked this and you are right. That's strange because it used to work... but it is not a big issue because I guess no one has used the Espressif's LWIP since years.

mikee47 · 2019-04-26T09:03:40Z

I've noticed that this PR consistently uses about 60 bytes more IRAM. I tracked this down to the Cache_Read_Enable_New() function in rboot-big-flash.c, which produces different code with -mforce-l32 enabled.
The previous makefiles only enabled the -mforce-l32 option for building the framework - it was conspicuously absent from project builds - but now both framework and app build with the same settings (defined in build.mk) which means -mforce-l32 is applied consistently.

slaff · 2019-04-26T09:16:11Z

... also Sming/apptest folder and its content can go away. Every platform can have its owns Tests folder where different unit tests can be stored. But tests and test frameworks is a whole new big topic that I don't want to mix in this PR.

Sming/third-party can be renamed to Sming/Components to be consistent with the platform folder structure and will be used for third-party code that is platform agnostic. Sming/Components and Sming/Platform/X/Components should use the same patching mechanism and organization.

mikee47 · 2019-04-26T10:46:08Z

Platform -> Platform/Esp8266/Platform

Wouldn't it be better to rename it to Platform/Esp8266? Without one more Platform at the end.

We've kind of appropriated Platform now to mean something a bit different - perhaps the code previously living in Platform may sit more comfortably in System instead?

It's also going to be more important to 'namespace' header files, thus:

  "AccessPoint.h"               ->    <Platform/AccessPoint.h> or <System/AccessPoint.h>
  "WiringFrameWorkIncludes.h"   ->    <Wiring/Framework.h>
  "gdb_hooks.h"                 ->    <gdb/hooks.h>
  <gdb_syscall.h>               ->    <gdb/syscall.h>
  "gdb/gdbstub-internal.h"      ->    <gdbstub/internal.h>
  "Services/SpifFS"             ->    <spiffs/spiffs.h>

This means Platform/Esp8266 cannot contain any code in the root directory.

custom_heap -> Platform/Esp8266/System/components/custom_heap

Why not Platform/Esp8266/Components/custom_heap ? Without the System part. The Components directory for every platform should be the place to store third-party libraries, components, etc. For example Platform/Esp8266/System/components/spiffs should be Platform/Esp8266/Components/spiffs

I chose to use lower-case components for consistency with the ESP-IDF - As there isn't a non-OS IDF framework for the ESP8266 this is the substitute. For the Esp32 components lives in the SDK.
Using Components as well may cause confusion or other issues, especially with Windows as it's not case sensitive. Regarding this and your point below about third-party, how about something different like ThirdParty, Shared, External, Import, etc?
(Notwithstanding, if the intention is to supplement IDF modules then it would go into components.)

appinit/user_main.cpp -> Platform/Esp8266/System/components/esp8266/startup.cpp

Why not Platform/Esp8266/AppInit/startup.cpp ? This is shorter and should be one of the files that every platform must implement.

Our startup.cpp contains lots of low-level stuff which the IDF takes care of, which is why I chose components/esp8266 to be an appropriate location.
The ESP8266 RTOS IDF implements this in components/esp8266/source/startup.c, and the ESP32 in components/esp32/cpu_start.c. We'd need to implement app_main() and call init(), that could could probably just go into Platform/Esp32/System/app_main.cpp.

Move Esp8266-specific files from system into Platform/Esp8266/System/components/esp8266

How about Platform/Esp8266/System/ ?

IDF

gdb -> Platform/Esp8266/System/components/gdbstub

Also Platform/Esp8266/Components/gdbstub.

IDF

... also Sming/apptest folder and its content can go away. Every platform can have its owns Tests folder where different unit tests can be stored. But tests and test frameworks is a whole new big topic that I don't want to mix in this PR.

OK.

Sming/third-party can be renamed to Sming/Components to be consistent with the platform folder structure and will be used for third-party code that is platform agnostic. Sming/Components and Sming/Platform/X/Components should use the same patching mechanism and organization.

The only thing in third-party which isn't platform-agnostic is ESP8266_NONOS_SDK. Feels a bit weird having that as a component.. I notice it's also (slightly) patched - is there any reason we're not using the current 3.0.0 release? I think it would be preferable to use an un-patched SDK and amend makefiles if necessary to accommodate the change from esp_init_data_default_v08.bin. We might also consider putting the SDK itself outside of the Sming repo...

Bugs found:

Testing with ENABLE_CUSTOM_LWIP=0 fails because of static definitions in mem_manager.h - also happens with existing build

Interesting. I have double checked this and you are right. That's strange because it used to work... but it is not a big issue because I guess no one has used the Espressif's LWIP since years.

Both esp-open-lwip and lwip2 have #include "mem_manager.h commented-out. If we do the same it builds, but haven't done any testing on a real device.

mikee47 · 2019-04-26T12:01:20Z

How's about this:

third-party/http_parser -> SmingCore/Network/Http/http_parser
third-party/mqtt-codec -> SmingCore/Network/Mqtt/mqtt-codec
third-party/libyuarel -> SmingCore/Network/Http/libyuarel
third-party/spiffs -> Platform/Esp8266/System/components/spiffs/spiffs
third-party/ws_parser -> SmingCore/Network/Http/Websocket/ws_parser

That just leaves ESP8266_NONOS_SDK to deal with.

There's also Services which feels a bit out of place.

Services/libb64 -> SmingCore/Network/libb64
Services/WebHelpers -> SmingCore/Network/WebHelpers

Not sure about these:

Services/HexDump ?
Services/CommandProcessing ?
Services/Profiling -> System ?
Services/Yeelight ?

mikee47 · 2019-04-26T12:39:05Z

Also, Libraries/ArduinoJson appears to be the only library referred to within the framework (by JsonObjectStream). That would suggest SmingCore/Data would be a better place for it?

-> We might also consider updating from V5.1.1 to version 6?

slaff · 2019-04-26T13:50:02Z

third-party/http_parser -> SmingCore/Network/Http/http_parser
third-party/mqtt-codec -> SmingCore/Network/Mqtt/mqtt-codec
third-party/libyuarel -> SmingCore/Network/Http/libyuarel

Better not. We should not mix our own-code with third-party code. Because it has its own coding styles, own compiler directives, etc. It would be much better to store external, third-party, libraries or components in strict predefined folder(s), for example

"Sming/Components" for all platform-agnostic third-party libraries, as mqtt-codec for example
"Sming/Platform/X/Components" for all platform specific third-party libraries.

That just leaves ESP8266_NONOS_SDK to deal with.

ESP8266_NONOS_SDK goes to `Sming/Platform/Esp8266/Components/Sdk/

Services/libb64 -> SmingCore/Network/libb64

No, that goes to Sming/Components/libb64

Services/WebHelpers -> SmingCore/Network/WebHelpers

Yes, that sounds like a good location.

Not sure about these:
Services/HexDump ?

Maybe SmingCore/Data/HexDump

Services/CommandProcessing ?

Maybe SmingCore/CommandProcessing

Services/Profiling -> System ?

Hm... You've got me...

Services/Yeelight ?

SmingCore/Drivers/Yeelight ?

slaff · 2019-04-27T14:26:14Z

Also, Libraries/ArduinoJson appears to be the only library referred to within the framework (by JsonObjectStream). That would suggest SmingCore/Data would be a better place for it?

Leave Libraries/ArduinoJson in its place. It is part of Sming but also an Arudino Library. No need to move it to Core or Data. At the moment at least.

We might also consider updating from V5.1.1 to version 6?

I will take a look and see if it is a lot of effort to migrate. Hopefully not.

mikee47 · 2019-04-27T14:33:48Z

As a way of dealing with the Platform/Esp8266/Platform issue, we could instead use Arch, so it would be Arch/Esp8266/Platform. We'd use SMING_ARCH to define the architecture, but Platform would retain its original meaning and source code.

(Also, Platform could be confused as meaning the development platform, i.e. Host)

...Or perhaps Target

slaff · 2019-04-27T15:14:14Z

I like both Arch and Target but would go for Arch just because it is shorter. So let it be Arch :)

mikee47 · 2019-04-27T15:26:19Z

At some stage we might introduce sub-architectures, something akin to 'boards' in Arduino, but perhaps more flexible so various system-dependent stuff can be more easily configured. All that is probably much easier to deal with in CMake though...

`Platform/Esp8266/app.mk` * Move variable statements before `flashinit` and `flash` rules (doesn't work otherwise) `Makefile` * Add `mkdir` for `libraries-clean` to improve reliablity (sometimes fails) * Add `submodules` and `submodules-clean` rules to replace `third-party` and `libraries` rules * Prioritise rules in `dist-clean`, put sample cleaning last

* Relocate submodules and tidy `.gitmodules` file * Move libsming definitions and MQTT flag into `build.mk` as they apply to both framework and application builds * Move SDK into `Arch/Esp8266/Sdk` and update to use Version 3 un-patched release

* Fix `decode-stacktrace.py` so pasting content works, using `raw_input()` instead of `input()`

mikee47 · 2019-04-29T09:25:56Z

With the above changes, we've got quite a clean set of 'root' directories:

Sming/Arch
Sming/Components
Sming/Core
Sming/Libraries
Sming/Platform
Sming/Services
Sming/Wiring

Note that Platform has been moved out of Core - it makes some sense to do this as it largely contains platform-specific code - but if you'd prefer it moved back to Core/Platform let me know.

I think it probably best to leave CommandProcessing, HexDump, Profiling and Yeelight where they are (in Services) for now - it will probably become clearer at some stage in development where they should actually go (if indeed they need moving at all).

I also have further changes to the makefiles, the goal being to document and clarify the existing build system to make it easier to migrate (e.g. to CMake), rather than adding anything new.

slaff · 2019-04-29T09:50:27Z

Note that Platform has been moved out of Core - it makes some sense to do this as it largely contains platform-specific code - but if you'd prefer it moved back to Core/Platform let me know.
...
I also have further changes to the makefiles, the goal being to document and clarify the existing build system to make it easier to migrate (e.g. to CMake), rather than adding anything new.

Perfect.

I think it probably best to leave CommandProcessing, HexDump, Profiling and Yeelight where they are (in Services) for now - it will probably become clearer at some stage in development where they should actually go (if indeed they need moving at all).

Yes, I agree with you.

We might also consider updating from V5.1.1 to version 6?
I will take a look and see if it is a lot of effort to migrate. Hopefully not.

Meanwhile the migration to ArduinoJson v6 is ready for testing #1677. The ArduinoJSON v6 API looks more elegant and intuitive. But we should check also the memory usage.

* Document relevant targets using `##` comments, groups with `##@` * Tag configuration variables using `CONFIG_VARS` so values can be examined (using `list-config`) * Add `help` and `list-config` targets * Add `rebuild` target for framework (app already has one) * Move `kill_term`, `terminal` and `decode-stacktrace` targets into `Makefile-app.mk` * Use CURDIR instead of fabricating CURRENT_DIR * Add `FixPath` function to deal with Windows/POSIX path conversion

…ing-style check

slaff

Fantastic work! Only few small but important things that will help/guide current users to migrate to v4 from 3.8.x.

Sming/Arch/Esp8266/Tools/decode-stacktrace.py

Sming/build.mk

Sming/building.md

slaff · 2019-04-30T07:52:36Z

samples/DFPlayerMini/app/application.cpp

@@ -1,5 +1,5 @@
 #include <user_config.h>
-#include <SmingCore/SmingCore.h>
+#include <SmingCore.h>


We should provide slightly smoother path to migrate to v4. Therefore I would suggest the following:

Create a Wiki page with the migration effort needed to migrate from v3.8.x to v4 (migrate-v3.8-v4.0)
As a start include just the update of the include: from <SmingCore/SmingCore.h> to <SmingCore.h>

Create SmingCore directory and put only SmingCore.h file in it.
SmingCore/SmingCore.h should
-> include Core/SmingCore.h.
-> Emit a #warning message that informs the user to update his include
-> And shows a link to the wiki migration page

I note you renamed the Wiki page for this, now the link is broken!

Thanks for noticing. Fixed with #1681.

slaff · 2019-04-30T07:54:16Z

samples/SmtpClient/app/application.cpp

-#include "SmingCore/SmingCore.h"
-#include "SmingCore/Network/SmtpClient.h"
+#include <SmingCore.h>
+#include <Network/SmtpClient.h>


The migration wiki should also include "recommended" way to update includes that are from SmingCore. Example:

"SmingCore/Network/SmtpClient.h" -> <Network/SmtpClient.h>.

Once the new file/folder layout has been fixed, before committing I'll need to do the following:

Fix #include guard naming

Update all #includes to use the recommended/namespaced convention

Fix #include guard naming

Or just use #pragma once. And then you will not need to fix them in the future.

Sming/Arch/Esp8266/Components/driver/uart.cpp

Sming/Makefile-app.mk

slaff · 2019-04-30T09:43:19Z

With the above changes, we've got quite a clean set of 'root' directories:
Sming/Arch
Sming/Components
Sming/Core
Sming/Libraries
Sming/Platform
Sming/Services
Sming/Wiring

I guess I forgot to mention that I like a lot the new structure. IMHO it is more intuitive than it used to be. So definitely a good way forward.

mikee47 · 2019-04-30T09:50:19Z

Something else we need to deal with is user_config.h which is heavily architecture-depdendent.
It's included for (almost) all of the sample applications (LiveDebug doesn't have it). They are all identical, except Basic_NFC, Accelerometer_MMA7455 and LED_YeelightBulb which override the baud rate to 115200 - I suspect that's an error.
I propose we remove all of these files, thus picking up the defaults in Arch/Esp8266/System/include/user_config.h. Other architectures may or may not require such a file.
Existing user applications should remove their user_config.h, although we need to consider what to do if users may have made any changes to the file.

I guess the characteristic of the file is that it (usually) gets #included ahead of anything else so is a good place to put overrides. How about this as a template for users to follow:

#pragma once
#include_next <user_config.h>

<< User Customisations here >>

slaff · 2019-04-30T09:53:27Z

Seems good to me. But I would prefer to have it as a separate PR so that it is, as you wrote once, "easier to digest".

mikee47 · 2019-04-30T10:46:54Z

The ARDUINO_LIBRARIES variable I kept from the previous makefile, but perhaps SMING_LIBRARIES would be better?

slaff · 2019-04-30T12:16:48Z

The ARDUINO_LIBRARIES variable I kept from the previous makefile, but perhaps SMING_LIBRARIES would be better?

Leave it as it is for the moment.

…order-only pre-requisites

…i migration page

…_input()` for consistent behaviour across python versions

…y with non-GNU `awk` implementations

Sming/building.md

Sming/SmingCore/SmingCore.h

mikee47 changed the title ~~Initial restructure to support multiple platforms~~ [WIP] Initial restructure to support multiple platforms Apr 27, 2019

mikee47 changed the title ~~[WIP] Initial restructure to support multiple platforms~~ [WIP] [RFC] Initial restructure to support multiple platforms Apr 27, 2019

mikee47 added 6 commits April 27, 2019 16:55

Use Arch directory instead of Platform

cd9919a

* Relocate submodules and tidy `.gitmodules` file * Move libsming definitions and MQTT flag into `build.mk` as they apply to both framework and application builds * Move SDK into `Arch/Esp8266/Sdk` and update to use Version 3 un-patched release

Add makefile rule to run stack trace and update instructions

f4f9b61

* Fix `decode-stacktrace.py` so pasting content works, using `raw_input()` instead of `input()`

Move Services/libb64 into Components

6c58abb

Move Services/WebHelpers into SmingCore/Network

1149ba8

Rename SmingCore to Core

e120909

mikee47 changed the title ~~[WIP] [RFC] Initial restructure to support multiple platforms~~ [WIP] [RFC] Initial restructure to support multiple target architectures Apr 28, 2019

slaff added this to the 3.9.0 milestone Apr 29, 2019

mikee47 added 5 commits April 29, 2019 16:55

WebHelpers now subject to coding style

78b419c

Add make help and make list-config to travis/appveyor, update cod…

a98ba2e

…ing-style check

Update Doxyfile

7a1d8c1

Fix esptool2 submodule dependency

3e68e58

slaff added the 3 - Review label Apr 30, 2019

slaff requested changes Apr 30, 2019

View reviewed changes

mikee47 added 7 commits April 30, 2019 14:20

Add individual .submodule dependencies for user libraries, make them …

100c6c9

…order-only pre-requisites

Add optional TRACE variable for decode-tracktrace target

85a5ea7

Add SmingCore/SmingCore.h legacy file with warnings and link to Wik…

bc3367e

…i migration page

In decode-stacktrace.py, use sys.stdin.readline() instead of `raw…

e849638

…_input()` for consistent behaviour across python versions

Remove sorting from PrintHelp make function to improve compatibilit…

b207eed

…y with non-GNU `awk` implementations

Replace #include guards with #pragma once

a8e25f6

Minor change to building.md

9fb2b9a

slaff reviewed Apr 30, 2019

View reviewed changes

Sming/building.md Outdated Show resolved Hide resolved

mikee47 added 2 commits April 30, 2019 14:48

Fix coding style

4498378

Fix line endings by running everything through dos2unix

f0ad288

slaff reviewed Apr 30, 2019

View reviewed changes

Sming/SmingCore/SmingCore.h Outdated Show resolved Hide resolved

Merge SmingCore warning #pragmas

c929c93

mikee47 changed the title ~~[WIP] [RFC] Initial restructure to support multiple target architectures~~ Initial restructure to support multiple target architectures Apr 30, 2019

slaff approved these changes May 1, 2019

View reviewed changes

slaff removed the 3 - Review label May 1, 2019

slaff merged commit 0e9832e into SmingHub:develop May 1, 2019

mikee47 deleted the platform-restructure branch May 1, 2019 14:38

mikee47 restored the platform-restructure branch June 18, 2019 20:52

slaff mentioned this pull request Jul 14, 2019

Preparation for Release 4.0.0 #1674

Closed

4 tasks

mikee47 deleted the platform-restructure branch August 3, 2019 11:16

mikee47 mentioned this pull request Jan 3, 2020

OTA upgrade as a component #2006

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initial restructure to support multiple target architectures #1675

Initial restructure to support multiple target architectures #1675

mikee47 commented Apr 25, 2019 •

edited

Loading

slaff commented Apr 26, 2019

mikee47 commented Apr 26, 2019 •

edited

Loading

slaff commented Apr 26, 2019

mikee47 commented Apr 26, 2019 •

edited

Loading

mikee47 commented Apr 26, 2019

mikee47 commented Apr 26, 2019 •

edited

Loading

slaff commented Apr 26, 2019

slaff commented Apr 27, 2019

mikee47 commented Apr 27, 2019 •

edited

Loading

slaff commented Apr 27, 2019

mikee47 commented Apr 27, 2019

mikee47 commented Apr 29, 2019 •

edited

Loading

slaff commented Apr 29, 2019 •

edited

Loading

slaff left a comment

slaff Apr 30, 2019

mikee47 May 3, 2019

slaff May 4, 2019 •

edited

Loading

slaff Apr 30, 2019 •

edited

Loading

mikee47 Apr 30, 2019

slaff Apr 30, 2019

slaff commented Apr 30, 2019 •

edited

Loading

mikee47 commented Apr 30, 2019

slaff commented Apr 30, 2019

mikee47 commented Apr 30, 2019

slaff commented Apr 30, 2019

Initial restructure to support multiple target architectures #1675

Initial restructure to support multiple target architectures #1675

Conversation

mikee47 commented Apr 25, 2019 • edited Loading

slaff commented Apr 26, 2019

mikee47 commented Apr 26, 2019 • edited Loading

slaff commented Apr 26, 2019

mikee47 commented Apr 26, 2019 • edited Loading

mikee47 commented Apr 26, 2019

mikee47 commented Apr 26, 2019 • edited Loading

slaff commented Apr 26, 2019

slaff commented Apr 27, 2019

mikee47 commented Apr 27, 2019 • edited Loading

slaff commented Apr 27, 2019

mikee47 commented Apr 27, 2019

mikee47 commented Apr 29, 2019 • edited Loading

slaff commented Apr 29, 2019 • edited Loading

slaff left a comment

Choose a reason for hiding this comment

slaff Apr 30, 2019

Choose a reason for hiding this comment

mikee47 May 3, 2019

Choose a reason for hiding this comment

slaff May 4, 2019 • edited Loading

Choose a reason for hiding this comment

slaff Apr 30, 2019 • edited Loading

Choose a reason for hiding this comment

mikee47 Apr 30, 2019

Choose a reason for hiding this comment

slaff Apr 30, 2019

Choose a reason for hiding this comment

slaff commented Apr 30, 2019 • edited Loading

mikee47 commented Apr 30, 2019

slaff commented Apr 30, 2019

mikee47 commented Apr 30, 2019

slaff commented Apr 30, 2019

mikee47 commented Apr 25, 2019 •

edited

Loading

mikee47 commented Apr 26, 2019 •

edited

Loading

mikee47 commented Apr 26, 2019 •

edited

Loading

mikee47 commented Apr 26, 2019 •

edited

Loading

mikee47 commented Apr 27, 2019 •

edited

Loading

mikee47 commented Apr 29, 2019 •

edited

Loading

slaff commented Apr 29, 2019 •

edited

Loading

slaff May 4, 2019 •

edited

Loading

slaff Apr 30, 2019 •

edited

Loading

slaff commented Apr 30, 2019 •

edited

Loading