-
Notifications
You must be signed in to change notification settings - Fork 22
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
Cmake source prep and building #46
Conversation
…ly fix include order
edit: see README-CMake.md |
Should the windows instructions be stored in this repo, in PIO repo, or in Tasmota repo ? Should the basic instructions be put on a README.cmake file ? I just tried on linux and compilation works (I have not tested the generated files though). However I would rename the variable I don't know in PIO how things work, but if |
Makes sense to update Building section? PIO is just a shortcut for getting toolchain + esp8266 Core files in the same step. edit: In any case, I will move build instructions (keeping in mind both IDE and PIO) Windows part too, I think? But I am failing hard at patching though:
Resulting firmware worked for me btw.
Makes sense, will rename and try to search for files there beforehand. And I also haven't done "release" install target yet to copy headers to the Core directory PIO toolchain and framework are separate packages:
|
patches/0003-dhcp-dhcp6-Ensure-that-DHCP-DHCPv6-DNS-server-update.patch
Outdated
Show resolved
Hide resolved
|
Have not tested that the binaries actually work, but patches apply and everything seems to be merged together correctly on Windows. And b/c it was 2y ago, need to go over the CFLAGS, lwipopts.h, etc. and check whether those are actually the same as the Makefile build There are also these after the install phase, in the esp8266 repo:
not sure what's the difference there just yet, I don't remember these extra includes copied |
These harmless files are unused copied from lwip's iclude files. I understand that this PR needs some more checks or am I wrong ? |
Right now it simply does
I was able to bootstrap it again from the README, so I think it's done. Let me do a once-over and wip could be removed. Have you tried it btw? and idk about the open-sdk part, but that may be added later. |
As mentioned in the other issue, this is general cmake setup to handle lwip2 source directory, it's patching and building liblwip.a for the esp8266/Arduino project.
How this works:
By default, build script will place the resulting library into the
output/lib
. This can be changed via-DLIB_INSTALL_DIR=<PATH-TO-TOOLS-SDK>
(without thelib/
, which is appended implicitly by the cmake tools. Not yet sure what is up with that and how to have a single one prefix configuration)edit: or, DESTDIR=..., which I even forgot about. but that need undo'ing the manual directory management in builder externalproject declaration
cmake/toolchain.cmake
,cmake/esp8266-platform.cmake
handle the toolchain part. cflags are taken from an existing makefile definitonscmake/builder.cmake
builds glue+lwip in the same step, combining .o as liblwip. Following lwip2 build guidelines:http://git.savannah.nongnu.org/cgit/lwip.git/tree/BUILDING
http://git.savannah.nongnu.org/cgit/lwip/lwip-contrib.git/tree/ports/unix/example_app/CMakeLists.txt
lwip project already provides lwip2-src/src/Filelists.cmake, and simply by including it registers
lwipcore
library with a proper source list. Additional modules config is taken from the same file definitions, simply appending module variable to thelwipcore
target sources listcmake/lwip<name>/CMakeLists.txt
are supposed to be for-loop replacement from the current makefile, listing things instead of dynamically generating them each time. see scripts/cmake-generateCMakeLists.txt
manages generated headers (err_t and hash string, see glue-lwip/*.h.in) and lwip2-src (upkeep, checkout, patch) and building eachcmake/lwip<name>
scripts/clean-lwip2-src and scripts/patch-lwip2-src are moved from makefile steps to handle patch invocation and git checkout & git clean
I don't think it is intended to replace existing setup (and with opensdk even wise to do so), but simply to have a general view of how the stuff works. Things are commented as much as possible, pinpointing some questions / problems / quirks with an existing setup.