Created attachment 220339 [details] devel/xtensa-esp32s2-elf my repository is available at: https://github.com/trombik/xtensa-esp32-elf
This seems to fail to configure due to a missing libintl.h: ./lkc.h:12:11: fatal error: 'libintl.h' file not found
Created attachment 220340 [details] log file
devel/xtensa-esp32-elf supports a project that can't yet upgrade from gcc 5.2.0 to 8.2.0. I propose a new xtensa-esp32-elf-devel port that tracks the latest esp-2020 tag. Does that work for you?
(In reply to Craig Leres from comment #3) in that case, devel/xtensa-esp32-elf33 devel/xtensa-esp32-elf40 devel/xtensa-esp32-elf would be better, where (33|40) is esp-idf release version.
I don't like the idea of tying the toolchain version to a specific idf version. For example this port might be used to build arduino sketches for the esp32. Also, this port is fairly expensive to build so I wouldn't want to see more than two different versions. And I'd prefer to not bake a specific version number into the port name. Looking around in the ports/lang tree, -devel looks to be the appropriate suffix.
(In reply to Craig Leres from comment #5) esp-idf only supports a specific version. as I a maintainer of esp-idf-lib, I would like to build code with multiple stable release versions of esp-idf. also, some libraries and projects are written for a specific esp-idf version. some libraries include binary blobs compiled for a specific version. each esp-idf version requires a specific toolchain. there are more than one stable esp-idf releases. how do you solve the problem?
(In reply to Craig Leres from comment #5) on my poudriere box with CURRENT and core-i7 (four cores), it was "build time: 00:54:12". not "fairly expensive".
(In reply to Tomoyuki Sakurai from comment #6) What I propose is to pick a current, recent toolchain and make it the -devel version. I see that esp-idf v3.3.3 and v3.3.4 want crosstool-ng-1.22.0-96-g2852398 so the current xtensa-esp32-elf works for them. It uses 1.22.0-97-gc752ad5 but as I understand it -97 backs out a PSRAM patch from -96 that turned out to be problematic. v4.0.1 uses esp-2019r2, v4.1 uses esp-2020r2, and v4.2 uses esp-2020r3. Based on your request to upgrade xtensa-esp32-elf to esp-2020r3 my assumption would be that you are interested in supporting esp-idf v4.2. I'm willing to accommodate that by creating xtensa-esp32-elf-devel based on esp-2020r3. But I don't think I want to support more than two versions nor do I want to load up the FreeBSD package build servers with a bunch of different versions that each take a non-trivial amount of time to build.
then, fine. thank you.
Can this please be revived? Fighting with this really unusable archaic JAVA based arduiono-esp32, I'd like to see something more sophiticated for development like the effort given to the FreeBSD community by Tomoyuki Sakurai. On recent CURRENT (also on 14-STABLE) the ports at https://github.com/trombik/xtensa-esp32-elf build well for me in poudriere and with portmaster and make.
As I've previously stated: devel/xtensa-esp32-elf supports a project that can't yet upgrade from gcc 5.2.0 to 8.2.0. [https://www.openvehicles.com/] I'm willing to create a port for one other version [xtensa-esp32-elf-devel] but no more that.
Comment on attachment 220340 [details] log file The shown build error doesn't show up with the most recent sources on most recent CURRENT.
(In reply to Craig Leres from comment #11) I can not see openvehicles as part of the FreeBSD ports collection, relying on this port. So I assume it is a private project of yours, not the community. Correct me when I'm wrong. The recent port is based on a quite outdated toolchain, gcc 5 versus recent gcc 12.
I made a suggestion, please see PR 278061 (rename the recent port with the outdated toolchain to devel/xtensa-esp32-elf-legacy) and PR 278062 (establish the new toolchain as suggested herein with modernisations, of course).
I would like to make it clear how I think about the ports I maintain on GitHub. I made them for myself. I maintain several ESP32 and ESP8266 libraries. My ports work for me. I am happy with them. I need FLAVORS because my libraries support all the supported releases of espressif toolchains. If you want the ports in the official ports tree, please remove my name from MAINTAINER. It takes a quite a bit of time to maintain the ports. Without help, I cannot maintain them nor be responsible for them. The current development model works quite well for me. I don't know much about openvehicles the maintainer care about. espressif stopped supporting esp-idf 3.x long time ago. Still, the following issue has been open for a year. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/908 If he needs it, let it be so. There are other tools that need to be ported for FreeBSD, tools to write HEX to chips, kernel drivers to talk to common serial port chips on development boards, tools to make FAT FS, supporting third-party tools, etc. espressif is quite open for proposals to fix issues on FreeBSD. However, I cannot handle all the issues from users without any possible fix. FreeBSD is quite a minority in this area, and I ask you to help building a community first. If you like the idea, help me in my GitHub repositories. Thank you.
(In reply to Tomoyuki Sakurai from comment #15) To be clear, you are not currently listed as MAINTAINER for any FreeBSD port (I just checked).