-
Notifications
You must be signed in to change notification settings - Fork 13.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration with @PlatformIO Build System #3321
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
{ | ||
"name": "framework-arduinoespressif8266", | ||
"description": "Arduino Wiring-based Framework (ESP8266 Core)", | ||
"url": "https://github.com/esp8266/Arduino", | ||
"version": "2.4.0-rc.1" | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,95 @@ | ||
# Copyright (c) 2014-present PlatformIO <[email protected]> | ||
# | ||
# Licensed under the Apache License, Version 2.0 (the "License"); | ||
# you may not use this file except in compliance with the License. | ||
# You may obtain a copy of the License at | ||
# | ||
# http://www.apache.org/licenses/LICENSE-2.0 | ||
# | ||
# Unless required by applicable law or agreed to in writing, software | ||
# distributed under the License is distributed on an "AS IS" BASIS, | ||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
|
||
""" | ||
Arduino | ||
|
||
Arduino Wiring-based Framework allows writing cross-platform software to | ||
control devices attached to a wide range of Arduino boards to create all | ||
kinds of creative coding, interactive objects, spaces or physical experiences. | ||
|
||
http://arduino.cc/en/Reference/HomePage | ||
""" | ||
|
||
# Extends: https://github.com/platformio/platform-espressif8266/blob/develop/builder/main.py | ||
|
||
from os.path import isdir, join | ||
|
||
from SCons.Script import DefaultEnvironment | ||
|
||
env = DefaultEnvironment() | ||
platform = env.PioPlatform() | ||
|
||
FRAMEWORK_DIR = platform.get_package_dir("framework-arduinoespressif8266") | ||
assert isdir(FRAMEWORK_DIR) | ||
|
||
|
||
env.Prepend( | ||
CPPDEFINES=[ | ||
("ARDUINO", 10600), | ||
"LWIP_OPEN_SRC" | ||
], | ||
CPPPATH=[ | ||
join(FRAMEWORK_DIR, "tools", "sdk", "include"), | ||
join(FRAMEWORK_DIR, "tools", "sdk", "lwip", "include"), | ||
join(FRAMEWORK_DIR, "tools", "sdk", "libc", | ||
"xtensa-lx106-elf", "include"), | ||
join(FRAMEWORK_DIR, "cores", env.BoardConfig().get("build.core")) | ||
], | ||
LIBPATH=[ | ||
join(FRAMEWORK_DIR, "tools", "sdk", "lib"), | ||
join(FRAMEWORK_DIR, "tools", "sdk", "ld"), | ||
join(FRAMEWORK_DIR, "tools", "sdk", "libc", "xtensa-lx106-elf", "lib") | ||
], | ||
LIBS=[ | ||
"mesh", "wpa2", "smartconfig", "espnow", "pp", "main", "wpa", "lwip_gcc", | ||
"net80211", "wps", "crypto", "phy", "hal", "axtls", "gcc", | ||
"m", "c", "stdc++" | ||
] | ||
) | ||
|
||
env.Append( | ||
LIBSOURCE_DIRS=[ | ||
join(FRAMEWORK_DIR, "libraries") | ||
], | ||
LINKFLAGS=[ | ||
"-Wl,-wrap,system_restart_local", | ||
"-Wl,-wrap,spi_flash_read" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it possible to pull these flags from platform.txt? As far as i can tell, platformio-build.py is normal Python program, so opening platform.txt and extracting flags from it seems to be quite doable. Otherwise the flags would need to be updated in two files... Something along the lines of what makeEspArduino does, but in Python. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Arduino Build System is a self-written bunch of files where they play with common problems which were resolved by We didn't invent the new wheel and our PIO Build System is based on SCons construction tool. It's 100% pure Python implementation with Zero-dependencies to other packages or even to the OS software. We applied a lot of patches to SCons to make it better for embedded using and now it's super-fast and reliable. In We would be thankful if you support this build script. I see that it doesn't require a lot of efforts. Take a look at platformio-build.py for ESP32 by @me-no-dev . I don't see here a hundred commits. In any case, you can ping me or @valeros any time and we will help as soon as possible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Can you point me to the description which flag option should be located in which scope? If there is such a description, it should be more or less straightforward to write the code which will parse flags from platform.txt and put them into the correct scopes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Most of the changes I have done to the file are because libs change often on ESP32, other than that I let PlatformIO be as it is. I have asked @ivankravets a couple of times when I implement a new core feature (like partitions), so it kinda helps keep both in sync. He would not need to read through every commit to learn that a new command/feature is required :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here is base build script for ESP8266. Build script from this PR extends that script. Also, full list with SCons construction variables There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, i'm reading these and given that there doesn't seem to be a strict rule which flag has to go where, i'm trying to find the pattern. Why do Another way of approaching this is generating both platform.txt and the platformio script from a single configuration file. That would likely be even more straightforward. Would reading these flags from some .json or .yml file work for you? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is base configuration. You can "override" all scopes with own flags/data. Use To dump current build environment, use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see that this is the base configuration, and i understand that it can be overridden... My question above was why these flags are in the ESP8266-specific configuration, when logically they should not be in the chip-dependent part. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is a good idea. I'm not sure but @projectgus works on the same for ESP-IDF. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Good question :) This is a historical problem. We had 1 script for ESP8266 in PlO 2.0 and kept inside PIO Core (2 years ago). 1 year ago we released PIO 3.0 with decentralized platforms where each platform using PIO Build API decides how to build own frameworks, SDKs, HALs, etc. Later, we added support for ESP8266 SDK and Simba framework. After that, we don't touch that part of code, need to check if Simba uses our default environment. In any case, we are open for discussion and PR. Feel free to make contribution to https://github.com/platformio/platform-espressif8266 |
||
] | ||
) | ||
|
||
# | ||
# Target: Build Core Library | ||
# | ||
|
||
libs = [] | ||
|
||
if "build.variant" in env.BoardConfig(): | ||
env.Append( | ||
CPPPATH=[ | ||
join(FRAMEWORK_DIR, "variants", | ||
env.BoardConfig().get("build.variant")) | ||
] | ||
) | ||
libs.append(env.BuildLibrary( | ||
join("$BUILD_DIR", "FrameworkArduinoVariant"), | ||
join(FRAMEWORK_DIR, "variants", env.BoardConfig().get("build.variant")) | ||
)) | ||
|
||
libs.append(env.BuildLibrary( | ||
join("$BUILD_DIR", "FrameworkArduino"), | ||
join(FRAMEWORK_DIR, "cores", env.BoardConfig().get("build.core")) | ||
)) | ||
|
||
env.Prepend(LIBS=libs) |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -157,6 +157,18 @@ SECTIONS | |
*.c.o( EXCLUDE_FILE (umm_malloc.c.o) .literal*, \ | ||
EXCLUDE_FILE (umm_malloc.c.o) .text*) | ||
*.cpp.o(.literal*, .text*) | ||
*.pioenvs\\*\\lib*.a:(EXCLUDE_FILE (umm_malloc.o) .literal*, \ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it possible to tweak object file names to make them same as in Arduino? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The same story. In PlatformIO (platformio.ini), you can have multiple build environment per a single project. For example: [env:release]
platform = espressif8266
framework = arduino
board = myboard
build_flags = -DRELEASE ... other flags
lib_deps =
StableLib@~1.2.3
otherLib@>2.0
[env:debug]
platform = espressif8266
framework = arduino
board = myboard
build_flags = -DDEBUG... other flags
lib_deps =
https://git.repo/stable.git
otherLib@~3.0 You will have 2 different build environments and the final objects will be located There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If this is the case, the build product may be different, because Arduino doesn't link libraries into archive files, an archive file is only produced for the "core". All object files from libraries get passed to the linker. This may have implications for libraries which override weak functions defined in the core. If the function within the library is placed into a separate object file, and this object file doesn't contain any other unresolved functions, the linker will not include this object file from the library into the final output. We don't happen to have this kind of situation now, but once we have it eventually, working around this may prove interesting :) But we have diverged from the original question... If you don't mind, i'll set up some code generation to create these extra LD script lines. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
PlatformIO Build System is very flexible. You can even override the WHOLE build process for a single library with a custom extra script. According to your question, library archiving is the default behavior. You are able to turn if off for specific library. See http://docs.platformio.org/en/latest/librarymanager/config.html#libarchive
No problem, thanks! For us would be good if you support this script. Users will be happy because will not be a delay "When we update script for new changes?". We have this problem for other 20 development platforms. Need to maintain all of them :( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That seems to be a library-level switch. Can we apply this switch at framework level? Also, back to my original question, is it possible to tweak object file names at framework level to make them the same as in Arduino? I.e. .c files get compiled into .c.o, .cpp into .cpp.o and so on? Directory layout doesn't matter much in this case, as the LD script currently has filename-dependent rules only.
Well, that's the part of platformio's value proposition, so there's probably no way around that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Currently, is not possible. Need to create
It's possible if build each file separately, see docs. We don't play with |
||
EXCLUDE_FILE (umm_malloc.o) .text*) | ||
*.pioenvs/*/lib*.a:(EXCLUDE_FILE (umm_malloc.o) .literal*, \ | ||
EXCLUDE_FILE (umm_malloc.o) .text*) | ||
*.pioenvs\\*\\lib\*.a:(EXCLUDE_FILE (umm_malloc.o) .literal*, \ | ||
EXCLUDE_FILE (umm_malloc.o) .text*) | ||
*.pioenvs/*/lib/*.a:(EXCLUDE_FILE (umm_malloc.o) .literal*, \ | ||
EXCLUDE_FILE (umm_malloc.o) .text*) | ||
*.pioenvs\\*\\src\\*.o(EXCLUDE_FILE (umm_malloc.o) .literal*, \ | ||
EXCLUDE_FILE (umm_malloc.o) .text*) | ||
*.pioenvs/*/src/*.o(EXCLUDE_FILE (umm_malloc.o) .literal*, \ | ||
EXCLUDE_FILE (umm_malloc.o) .text*) | ||
*libc.a:(.literal .text .literal.* .text.*) | ||
*libm.a:(.literal .text .literal.* .text.*) | ||
*libgcc.a:_umoddi3.o(.literal .text) | ||
|
@@ -205,6 +217,12 @@ SECTIONS | |
*(.literal .text .literal.* .text.* .stub .gnu.warning .gnu.linkonce.literal.* .gnu.linkonce.t.*.literal .gnu.linkonce.t.*) | ||
*.cpp.o(.iram.text) | ||
*.c.o(.iram.text) | ||
*.pioenvs\\*\\lib*.a:(.iram.text) | ||
*.pioenvs/*/lib*.a:(.iram.text) | ||
*.pioenvs\\*\\lib\\*.a:(.iram.text) | ||
*.pioenvs/*/lib/*.a:(.iram.text) | ||
*.pioenvs\\*\\src\\*.o(.iram.text) | ||
*.pioenvs/*/src/*.o(.iram.text) | ||
*(.fini.literal) | ||
*(.fini) | ||
*(.gnu.version) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to keep this in sync with platform.txt?
I would probably go with 2.4.0-dev or something along these lines for git version, because -rc1 is a quite specific tagged version...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2.4.0-dev
is good, but need to update it to the final release if you make release tag.Currently, we have own forked and patched ESP826 Core for Arduino. Our community does not like it and asks us to use your repository. That is why I added
package.json
manifest. It's required for PIO Package Manager. After merge/release, I'll switch our development platform to this repo here.