Page MenuHomeFreeBSD

emulators/wine-devel: Change tested variable for master port detection
ClosedPublic

Authored by salvadore on Mar 23 2020, 4:31 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 10 2024, 11:57 AM
Unknown Object (File)
Jan 30 2024, 1:04 PM
Unknown Object (File)
Jan 30 2024, 1:04 PM
Unknown Object (File)
Dec 20 2023, 5:31 AM
Unknown Object (File)
Dec 13 2023, 10:34 AM
Unknown Object (File)
Nov 29 2023, 5:41 PM
Unknown Object (File)
Nov 29 2023, 5:40 PM
Unknown Object (File)
Nov 24 2023, 2:06 PM
Subscribers

Details

Summary

It has been observed that the target config-recursive for emulators/i386-wine-devel can cause bsd.port.mk to be included twice when run in i386 jails. This seems to be due to the fact that config-recursive ignores PKGNAMEPREFIX definition, which is used in emulators/wine-devel to test wether bsd.port.[pre|post.]mk needs to be included or bsd.port.mk has already been included by i386-wine-devel. We change the testing variable to WINE_SLAVE_BUILD, defined in i386-wine-devel/Makefile.i386.

Test Plan
  • Run successfully make config-recursive in i386 jails.
  • Run successfully poudriere options -a i386 i386-wine-devel.
  • Build i386-wine-devel and wine-devel ports successfully on poudriere for all supported architectures (i386, amd64).

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

MASTERDIR breaks wine-devel. Try with _POSTMKINCLUDED, which is what bsd.port.mk uses at line 1580.

Still not the good test: i386-wine-devel does not work with _POSTMKINCLUDED.
I need to study better the issue.

Try with WINE_SLAVE_BUILD variable, defined in emulators/i386-wine-devel/Makefile.i386. I would have liked to remove that variable later, but apparently it can still be useful.

Here is what I wrote yesterday, but failed to hit "Submit":

Checking for _POSTMKINCLUDED looks like using a deep implementation detail - in general, variables whose name starts with an underscore indicate that.
Is there another way you can think of? Perhaps one that obviates this

Here is what I write today (and I shall hit "Submit" ;-):

Approved by: gerald (maintainer, mentor)
This revision is now accepted and ready to land.Mar 24 2020, 12:13 PM

Thanks, I will commit it if all tests passes.
I hope @scf can find the time to look at this review since he is one of the users who reported it, if I recall correctly.

Committed. If this commit works as expected, we will need to forward it to emulators/wine, as emulators/i386-wine is affected by the same bug.

Committed. If this commit works as expected, we will need to forward it to emulators/wine, as emulators/i386-wine is affected by the same bug.

Yes, and I hereby pre-approve (as both maintainer and mentor). Let's first get i386-wine-devel updated and out there for a week or two, and await any potential feedback from that end before backporting this change (and further ones to i386-wine-devel itself).

While I am late to the review, I was able to build i386-wine-devel-5.4,1 in an i386 jail and subsequently, within a amd64 jail. Thank you!

In D24167#532246, @scf wrote:

While I am late to the review, I was able to build i386-wine-devel-5.4,1 in an i386 jail and subsequently, within a amd64 jail. Thank you!

Great! Thanks for feedback!

This comment was removed by salvadore.