Paths

Table of Contentst

New port: devel/xtensa-esp32-elf - build the Espressif ESP32 toolchain to support Arduino and FreeRTOS projects
ClosedPublic
Actions

Authored by leres on May 2 2018, 8:15 PM.

Details

Reviewers

ler
matthew

Commits

rP468990: This adds devel/xtensa-esp32-elf which builds the Espressif

Summary

For some reason the cross-compile build does not make any of the
binaries executable; portlint didn't seem to like me using ${CHMOD}
to fix this so I added @mode lines to pkg-plist. I don't like this
though because it makes it more work to update pkg-plist (i.e. you
can't just "make makeplist"). What I think would be cleaner would
be to fix permissions in post-build.

I need to create a version.sh script so that gcc and friends report
the version of crosstool-ng used:

ice 486 % xtensa-esp32-elf-gcc --version
xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

printf/CHMOD seemed like a good way.

pre-configure could be merged into do-configure and pre-build and
post-build into do-build but it made more sense to me to keep them
split out, especially when testing.

Is COMMENT ok? (Is COMMENT even required given the detailed pkg-descr?)

It was suggested I use BINARY_ALIAS to get gcc and python on PATH
but create-binary-alias happens slightly before do-configure and
gcc at least must exist when configure runs. I suspect adding
gcc:lang/gcc and python:lang/python to BUILD_DEPENDS will raise
flags but this seemed cleaner to me than patching or using
REINPLACE_CMD, especially considering this currently builds without
any patches. And the current default USES=gcc is gcc6, I don't want
the port to break if/when this changes. (I really believe USES=gcc
should provide something called gcc on the PATH, no matter whate
version it is..)

Proposed commit message:

This adds devel/xtensa-esp32-elf which builds the Espressif
ESP32 toolchain for use with Arduino and FreeRTOS projects.

Reviewed by: ? (mentor)
Approved by: ? (mentor)
Differential Revision: ?

Diff Detail

Repository

rP FreeBSD ports repository

Lint

No Lint Coverage

Unit

No Test Coverage

Build Status

Buildable 16408
Build 16329: arc lint + arc unit

Event Timeline

leres created this revision.May 2 2018, 8:15 PM

Herald added a subscriber: mat. · View Herald TranscriptMay 2 2018, 8:15 PM

Harbormaster completed remote builds in B16401: Diff 42076.May 2 2018, 8:15 PM

Yes, you need a COMMENT line -- it's required in all ports. What you have is fine.

You should be able to avoid the @mode settings in the plist by setting the execute bit on the files
installed in ${STAGEDIR} as part of the do-install target.

devel/xtensa-esp32-elf/Makefile
43	Adding gcc:lang/gcc to BUILD_DEPENDS is redundant here: USE_GCC already does that for you.
51	Don't add python to the BUILD_DEPENDS like this. You're already using USES= python:build That's sufficient. It will add the default version of python to the BUILD_DEPENDS for you. Does this work with all versions of python -- particularly python27 vs python36 ?

Remove gcc and python from BUILD_DEPENDS, fully understand how BINARY_ALIAS works and use PATH from MAKE_ENV when building.

Change USES=python:build to just USES=python; we'll want python for xtensa-esp32-elf-gdb at run time (which the docs say works with python 2 and 3).

Fix permissions in do-install instead of pkg-plist and use COPYTREE_BIN instead of COPYTREE_SHARE.

NO_MTREE=yes

Fix some whitespace (why didn't portlint catch it?)

Harbormaster completed remote builds in B16408: Diff 42085.May 3 2018, 3:31 AM

leres marked 2 inline comments as done.May 3 2018, 3:36 AM

leres added inline comments.

devel/xtensa-esp32-elf/Makefile
43	Now using BINARY_ALIAS instead.
51	Now using BINARY_ALIAS instead. The gdb doc says it works with python 2 and 3.

(It still says I have 4 unsubmitted comment.)

Test builds I ran overnight all failed on 10.3-RELEASE due to 'bad C++ code' in many of the dependencies. Of course, since yesterday I should be testing on 10.4-RELEASE...

In D15271#322012, @matthew wrote:

Test builds I ran overnight all failed on 10.3-RELEASE due to 'bad C++ code' in many of the dependencies. Of course, since yesterday I should be testing on 10.4-RELEASE...

I spent the last few weeks upgrading ~50 systems from 10.3 to 11.1-RELEASE (starting with my build servers), should I create a 10.4-RELEASE jail to test with?

In D15271#322013, @leres wrote:

In D15271#322012, @matthew wrote:

Test builds I ran overnight all failed on 10.3-RELEASE due to 'bad C++ code' in many of the dependencies. Of course, since yesterday I should be testing on 10.4-RELEASE...

I spent the last few weeks upgrading ~50 systems from 10.3 to 11.1-RELEASE (starting with my build servers), should I create a 10.4-RELEASE jail to test with?

Yes -- although you don't need a stand-alone machine to do it. You can just use poudriere jails of the appropriate OS version. I have a setup like this:

lucid-nonsense:~:% poudriere jail -l
JAILNAME      VERSION             ARCH  METHOD       TIMESTAMP           PATH
10_4a         10.4-RELEASE-p8     amd64 ftp          2018-05-03 08:04:22 /usr/local/poudriere/jails/10_4a
10_4i         10.4-RELEASE-p8     i386  ftp          2018-05-03 09:34:49 /usr/local/poudriere/jails/10_4i
11_1a         11.1-RELEASE-p9     amd64 http         2018-04-04 22:02:41 /usr/local/poudriere/jails/11_1a
11_1i         11.1-RELEASE-p9     i386  http         2018-04-04 22:04:39 /usr/local/poudriere/jails/11_1i
stable11amd64 11.1-STABLE 1101513 amd64 src=/usr/src 2018-04-04 22:06:28 /usr/local/poudriere/jails/stable11amd64

and I have a bunch of different ports trees to play with too:

lucid-nonsense:~:% poudriere ports -l
PORTSTREE   METHOD TIMESTAMP           PATH
default     svn    2018-05-01 06:47:49 /usr/ports
development none   2016-03-25 12:04:24 /home/matthew/work/ports
github      null   2017-10-21 08:00:24 /home/matthew/work/github/freebsd-ports

and I have a small script that just loops through the different jails building everything in the different environments.

lucid-nonsense:~/src/scripts:% cat test-build.sh
#!/bin/sh

# @{#} $Id$
#
# Build ports from my development tree under a series of
# different OS version and architecture combinations
#
# We want to build all possible flavours, so:
#  - append '@all'
#  - use 'bulk -t' rather than 'testport'

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
export IFS='
'
umask 022

: ${POUDRIERE_PORTS:=development}
: ${POUDRIERE_SET:=development}
: ${POUDRIERE_JAILS:='11_1a 11_1i 10_4a 10_4i'}

tmp=${TMPDIR:-/tmp}

for j in $POUDRIERE_JAILS; do
    for origin in ${1+$@}; do
	pkg=${origin##*/}

	poudriere bulk -t -j $j -z $POUDRIERE_SET -p $POUDRIERE_PORTS \
		  ${origin}@all | tee ${tmp}/${pkg}_${j}.testport
    done
done

#
# That's All Folks!
#

The stable11amd64 jail and default ports are where I build the packages used on my home machines: all the others are used for testing.
I'd have a HEAD jail as well, but the machine hosting all that is on 11.2-STABLE, and you can have a more recent jail on an older host.

I have more than one poudriere jail on my systems, I just stopped using the 10.3-RELEASE ones a few weeks ago.

I updated my 10.3 jail to 10.4 (took forever -- should have just nuked it and created a new one from scratch) and started up a build and the only problem I see is that git refuses to build:

You are using OpenSSL from ports and have selected GSSAPI from base, please select another GSSAPI value

But it was because I had a make.conf in etc/poudriere.d, I reworked my poudriere.d make.conf configs so I can build with an empty make.conf and everything builds ok:

build started at Thu May  3 10:35:30 PDT 2018
port directory: /usr/ports/devel/xtensa-esp32-elf
package name: xtensa-esp32-elf-1.22.0.g20171219
building for: FreeBSD zinc.ee.lbl.gov 10.4-RELEASE-p8 FreeBSD 10.4-RELEASE-p8 amd64
maintained by: leres@freebsd.org
Makefile ident:
Poudriere version: 3.2.6
Host OSVERSION: 1101001

[...]

    [45:05] / 
    [INFO ]  Cleaning-up the toolchain's directory: done in 1.00s (at 45:05)

    [45:05] / 
    [INFO ]  Build completed at 20180503.182059

    [45:05] / 
    [INFO ]  (elapsed: 45:05.00)

    [45:05] / 
    [INFO ]  Finishing installation (may take a few seconds)...

    [45:05] / gmake[1]: Leaving directory '/wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-80-g6c4433a5'
    cd /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-80-g6c4433a5/builds/xtensa-esp32-elf &&  /bin/rm -f build.log.bz2 lib/charset.alias
    ===========================================================================
    =>> Checking for filesystem violations... done
    =======================<phase: run-depends    >============================
    ===>   xtensa-esp32-elf-1.22.0.g20171219 depends on file: /usr/local/bin/python2.7 - found
    ===>   xtensa-esp32-elf-1.22.0.g20171219 depends on executable: gcc6 - found
    ===========================================================================
    =>> Recording filesystem state for prestage... done
    =======================<phase: stage          >============================
    ===>  Staging for xtensa-esp32-elf-1.22.0.g20171219
    ===>   xtensa-esp32-elf-1.22.0.g20171219 depends on file: /usr/local/bin/python2.7 - found
    ===>   xtensa-esp32-elf-1.22.0.g20171219 depends on executable: gcc6 - found
    ===>   Generating temporary packing list
    cd /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-80-g6c4433a5/builds &&  /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&  /usr/bin/find -Ed $1 $3 \(   -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} +  -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 555 "$@"'\'' . {} + \)' COPYTREE_BIN xtensa-esp32-elf /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/stage/usr/local
    /usr/bin/find /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/stage/usr/local/xtensa-esp32-elf -type f |  /usr/bin/xargs /bin/chmod -wx
    /usr/bin/find /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/stage/usr/local/xtensa-esp32-elf/bin  /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/stage/usr/local/xtensa-esp32-elf/libexec/gcc/xtensa-esp32-elf/5.2.0  /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/stage/usr/local/xtensa-esp32-elf/xtensa-esp32-elf/bin -type f |  /usr/bin/xargs /bin/chmod +x
    ====> Compressing man pages (compress-man)
    ===>   Installing ldconfig configuration file
    ===========================================================================
    ====> Running Q/A tests (stage-qa)
    Warning: 'xtensa-esp32-elf/libexec/gcc/xtensa-esp32-elf/5.2.0/plugin/gengtype' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
    Error: /usr/local/xtensa-esp32-elf/bin/xtensa-esp32-elf-gdb is linked to /usr/local/lib/libintl.so.8 from devel/gettext-runtime but it is not declared as a dependency
    Warning: you need USES+=gettext-runtime
    ====> Checking for pkg-plist issues (check-plist)
    ===> Parsing plist
    ===> Checking for items in STAGEDIR missing from pkg-plist
    ===> Checking for items in pkg-plist which are not in STAGEDIR
    ===> No pkg-plist issues found (check-plist)
    =>> Checking for staging violations... done
    =======================<phase: package        >============================
    ===>  Building package for xtensa-esp32-elf-1.22.0.g20171219
    ===========================================================================
    =>> Recording filesystem state for preinst... done
    =======================<phase: install        >============================
    ===>  Installing for xtensa-esp32-elf-1.22.0.g20171219
    ===>  Checking if xtensa-esp32-elf already installed
    ===>   Registering installation for xtensa-esp32-elf-1.22.0.g20171219
    [zinc.ee.lbl.gov] Installing xtensa-esp32-elf-1.22.0.g20171219...
    ===========================================================================
    =>> Checking shared library dependencies
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.7]
     0x0000000000000001 (NEEDED)             Shared library: [libintl.so.8]
     0x0000000000000001 (NEEDED)             Shared library: [liblzma.so.5]
     0x0000000000000001 (NEEDED)             Shared library: [libm.so.5]
     0x0000000000000001 (NEEDED)             Shared library: [libncurses.so.8]
     0x0000000000000001 (NEEDED)             Shared library: [libpython2.7.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libutil.so.9]
     0x0000000000000001 (NEEDED)             Shared library: [libz.so.6]
    =======================<phase: deinstall      >============================
    ===>  Deinstalling for xtensa-esp32-elf
    ===>   Deinstalling xtensa-esp32-elf-1.22.0.g20171219
    Updating database digests format: .......... done
    Checking integrity... done (0 conflicting)
    Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

    Installed packages to be REMOVED:
	    xtensa-esp32-elf-1.22.0.g20171219

    Number of packages to be removed: 1

    The operation will free 125 MiB.
    [zinc.ee.lbl.gov] [1/1] Deinstalling xtensa-esp32-elf-1.22.0.g20171219...
    [zinc.ee.lbl.gov] [1/1] Deleting files for xtensa-esp32-elf-1.22.0.g20171219: .......... done
    ===========================================================================
    =>> Checking for extra files and directories

Yes, everything builds just fine on 10.4 and 11.1, which are the currently supported versions.

lgtm