A FreeBSD User <freebsd_at_walstatt-de.de> wrote on Date: Thu, 25 Sep 2025 18:10:45 UTC :
> 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, > > > > > >. . . > > > > > > 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): > > > > > >. . . > > > > . . . > > > > . . . As mentioned, poudriere does the job in its obscure ways. . . . [I'm not trying to reference any build-time-frame issues here. I'm also limiting this to one aspect or test for helping isolate the issue, by having a context that does not, of itself, involve poudriere(-evel) doing the build of the problem port yet that I expect would work.] Replicating what poudriere does for building a specific port-package is conceptually rather simple, presuming prior builds of the the port-packages for each build-dependency, and for covering each library-dependency, and for each run-dependency: ) Start from a clean installation of a chroot/jail world (no packages) ) Install pkg ) Install the port-packages for the dependencies referenced ) (if correctly done: here only the 1 specific port/package needs to be built) ) build the problematical port via make ) create the package from the installed port I expect that if you did this for the failing port you would find that the "build the problematical port via make" would work just fine. I'll note that just using "make" as the overall way to build installs more into the system than is indicated to install above --and leaves it there for later stages of the activity as it goes along. What I expect is that the interference with the build is from some of those extra installations. But I've never managed to identify what injects the "-D" when looking at past submittals of examples of the "-D" injection problem: sysutils/edk2 [Bug 280076] sysutils/u-boot-pine64 [Bug 281730] Various ports do not meet the criteria of being invariant for their build behavior when varying what other ports are already installed at the time make tries to build the port in question. Implementing such invariance for such changes in context can be difficult. Contributions to an example lack of invariance can be difficult to track down. In part the above is from considering how I might manage to better isolate a smaller example that shows the injection of the "-D" by mixing in some, but not all of the "extra" installs that stick around when make is used as the overall way to build. I do not claim that I'll make progress any time soon. But it seems to be a potential way forward. === Mark Millard marklmi at yahoo.com
