Re: SETENVI, make "port" and poudriere weirdness

A FreeBSD User <freebsd_at_walstatt-de.de> wrote on
Date: Sat, 27 Sep 2025 09:06:41 UTC :

> Am Tage des Herren Fri, 26 Sep 2025 17:56:08 +0200
> Tijl Coosemans <[email protected]> schrieb:
> 
> > On Thu, 25 Sep 2025 20:10:45 +0200 A FreeBSD User wrote:
> > > 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: 
> > >>> . . .
> > >> 
> > >> . . .
> > > 
> > > 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 . . .
> > > . . .
> 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 . . . 
> > > . . . When patching the portions of the Makefile responsible for
> > > building, I'm able to get rid of the " : invalid option -- D" issue

Are you going to publish a patch that updates the
files to as you have them so that someone else can
attempt to reproduce your problem for after the
above has been done? A point of that is to make sure
to have the same file contents that you are using
for the unofficial port if someone tries.

> -
> > > 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. . . .
> > > 
> > > 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

[poudriere here is non-essential and not part of
the problem, there is a manual sequencing that
would have the same sort of build context. (I
sent a message about this earlier.)]

> and the make/portmaster
> > > does not. 
> > > 
> > > Kind regards and thanks,
> > > Oliver 
> > 
> > You'll have to make all the same changes to the overlay that
> > b8bbb207f55db made: add WRK_ENV and replace all SETENV with SETENVI.
> 
> I do, I did, of course.

Again, can you provide a patch that others might
use to reproduce the resultant files?

> The overlay used in poudriere doesn't have any issue.
> 
> The issue arise using portmaster, then this spooky mixing up of make/gmake occurs and can be
> resolved by addapting ${SETENVI} at places where ${SETENVI} is residing, sometimes adding
> ${WRK_ENV} additionaly.

Again, can you provide a patch that others might
use to reproduce the resultant files?

> The overlay used in poudriere doesn't have any is
> 
> In most cases the issue occurs in "build" or "do-build" (of the make framework).
> 
> In the reported case this is complete gone wild, even "make all" starts getting rogue,
> 
> I focussed too much on the "do-build" or "build" part of the Makefile, maybe also the
> "do-configure" and "configure" parts are highly sensitive to this SETENV/SETENVI issue. There
> fore, one has too understand the software the FreeBSD's port system is targetting for - and I
> do not ...
> 
> And, for a reminder, I'm confused by this port (not officially in the ports tree):
> 
> https://github.com/trombik/xtensa-esp32-elf 
> and from there
> devel/xtensa-esp-elf
> devel/riscv32-esp-elf
> 
> both toolchains targetting all available ESP-IDF (5.3, 54 and 5.5 as of today). adapting and
> building with poudriere - no problem. Having a "polluted" ports tree with this specific port,
> even "portmaster" AND "make all" fail 
> 
> 
> > 
> > . . . 
> > 
> 


===
Mark Millard
marklmi at yahoo.com