Re: SETENVI, make "port" and poudriere weirdness

Am Tage des Herren Wed, 24 Sep 2025 19:17:23 +0200
Tijl Coosemans <[email protected]> schrieb:

> On Wed, 24 Sep 2025 13:46:07 +0200 A FreeBSD User wrote:
> > Hello,
> > 
> > running FreeBSD CURRENT and FreeBSD 15-STABLE on several machines, I
> > face some issues with the traditional way of compiling ports and the
> > more resource-eating way with poudriere.
> > 
> > Some ports when compiled via "cd /usr/ports/PORT; make all" do fail
> > with an obscur error reporting
> > 
> > : invalid option -- D
> > 
> > followed by a bunch of gmake options (for instance see PR 277961,
> > x11-wm/libwraster which is still open). Those ports fail in an
> > "unclean natural" environment while compiling in the artificial
> > sterile poudriere environment. In almost all cases the problem is due
> > to "overlapping" environments, targeted by the introduction of SETENVI
> > - see /usr/ports/CHANGES, tag 20240229:.
> > 
> > I try to compile a well maintainded ESP32 toolchain
> > (https://github.com/trombik/xtensa-esp32-elf, here:
> > devel/riscv32-esp-elf and/or devel/xtensa-esp-elf).
> > 
> > The non-official port compiles flawless within recent FreeBSD CURRENT
> > and 15-STABLE with poudriere-devel. 
> > 
> > It fails on all boxes running CURRENT and 15-STABLE  using "make all":
> > It fails in those portions of the make process while "do build" uses
> > ${SETENV} instead of ${SETENVI} [${WRK_ENV}]. After fixing that I'm
> > stuck in the last step of do-build:
> > 
> > I do not want to go into too much details here since I want to point
> > out that the real world "make all" differs in a significant way from
> > the artificial sterile way of doing poudriere (which is to much efford
> > on development/experimental platforms where we change options very
> > often).
> > I'd like to understand the underlying behaviour to fix the
> > misbehaviour in "make all" - this seems to be very hard and I fear
> > that I miss something, some knowledge about the PORTS framework, the
> > role of the environment and so on. I almost changed EVERY posiible
> > permutation of the line (see Makefile of xtensa-esp-elf):
> > 
> > [...]
> > 
> > do-build:
> > ORIG:
> >     cd ${BUILD_WRKSRC} && ${SETENV} ${MAKE_ENV} ${BUILD_ENV} ./ct-ng build
> > VARIANT1:
> > 	cd ${BUILD_WRKSRC} && ${SETENVI} ${MAKE_ENV} ${BUILD_ENV} ./ct-ng build
> > VARIANT2:
> > 	cd ${BUILD_WRKSRC} && ${SETENVI} ${WRK_ENV} ${MAKE_ENV} ${BUILD_ENV} ./ct-ng build
> > 
> > 
> > The great magic here seems to be one needs to understand the
> > difference between poudriere's enviroenment and the environment of my
> > account on several boxes. My (blunt and stupid) approach is to replace
> > on a bail out the first occurence of "${SETENV}" with "${SETENVI}
> > ${WRK_ENV}" as suggested in the above mentioned reference in CHANGES.  
> 
> Is your ports tree up to date because this appears to have been fixed in
> https://cgit.freebsd.org/ports/commit/?id=b8bbb207f55db
> 

Sorry for  late responding.
I made it a habit to keep almost everything on a daily basis up to date and before compiling a
port or something related to the OS I do a pull (git).

The port deve/xtensa-esp-elf is the official port in the ports tree. The port does not cover
ESP32 RISCV32 based and doesn't cover latest ESP-IDF 5.5.

I try to
compile  https://github.com/trombik/xtensa-esp32-elf which does compile fine as long as it is compiled in poudriere (also up to date with up to date trees and an overlay covering the additional port). As mentioned, poudriere does the job in its obscure  ways. Replacing the port devel/xtensa-esp-elf with the port by this Japanese developer mentioned above in the tree an running either portmaster or make all does fail as I described above. I refered to some ports and PRs with similar issues - and in most cases with those ports, the introduction of SETENVI solves the problem. But not with the reluctant port from github. When patching the portions of the Makefile responsible for building, I'm able to get rid of the
" : invalid option -- D" issue - of which the cukprit mutually has been identified but then I
run in seroius trouble at the Makefile's section  "do-build": the process then complains about
missing source file archive (picolibc-esp) - which is definitely present and which is not
complained about by the poudriere build process.
At this point I'm pretty confident that poudriere and the traditional way are different, q.e.d.

I'd like to understand to fix the problem, otherwise I'm drifting around like a dead man in
the water hoping others fix the problem by accident. That is not an option. I'd like to
understand why poudriere builds the unaltered port without any flaws and the make/portmaster
does not. 

Kind regards and thanks,
Oliver

-- 

A FreeBSD user

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaNWFwAAKCRCxzvs8Oqok
r6vAAP9bku4fO0EKcZ6rWahq0YPv++z8G65373ssNFcAqAdLHAEAiR9SR+lNTUyW
roTkNIHbDZQTBeGM9W3VsdV5kyXH/gs=
=+T0K
-----END PGP SIGNATURE-----