emulators/i386-wine-devel: Transform maintainance target into script

[salvadore]

Summary

The distinfo-update target does not work: it generates errors about "fetch" and "makesum" targets not being defined due to the fact that distinfo-update calls submakes within the port's Makefile. We solve the issue by transforming the target into an indipendent script.

The change does not affect users in any way.

[gerald]

First a general question, then specific comments:

How does this fail for you, Lorenzo? I just gave it a try on 11.3-STABLE/amd64 and 12.1-STABLE/amd64 and it worked like a charm. That is, it regenerated exactly the same distinfo fileas is in SVN right now, except for a newer TIMESTAMP.

(I never did this before, and there is no documentation I could find, but playing a bit

make NO_DEPENDS=1 distinfo-update

did the trick. Where and how did you try?)

In terms of specific feedback, the first half of the script made my head hurt a little. Could you make that check

if [ "$(basename $(pwd))" != "$PORT" ]; then
:

And maybe abstract the list "11 12 13" into a variable at the top of the script, so that one only has to change anything there in the future?

But first let's understand why the current implementation fails for you when it appears to for me.

[gerald]

x663 BDownload

is one simplification we could make, though (in any case, keeping the Makefile or adding the script)?

[salvadore]

As I anticipated to you in a recent mail, the error only happens randomly: indeed, today it works for me as well. I even tried to reproduce it on the reference machines, but it works great there as well. And yet, I did verify that it was broken before preparing this review...
I do not think I changed anything important on my system since last time I saw the error: I have not updated my ports tree, I have not moved it... Only thing I did was a base world rebuild to enable profiling, but without updating the revision.
Unless I remember wrongly of course...

When the error appears it consists in make complaining about targets fetch and makesum not being defined. I run 13.0-CURRENT r360656.

I will try to investigate better on the issue and then I will update the revision consistently with your wise suggestions. Indeed using basename is much simpler :) I should have thought about it.

[salvadore]

I think I found how to reproduce the bug on my machine:

• define WRKDIRPREFIX;
• create the directory ${WRKDIRPREFIX}${.CURDIR}, where .CURDIR has the same value than in emulators/i386-wine-devel. Example: if you have your ports tree in /usr/ports then create the directory ${WRKDIRPREFIX}/usr/ports/emulators/i386-wine-devel;
• run make distinfo-update in i386-wine-devel.

However, this does not reproduce the issue on the reference machines, so there must be something more that I missed.

I will investigate more.

[gerald]

In D25042#552236, @salvadore wrote:

When the error appears it consists in make complaining about targets fetch and makesum not being defined. I run 13.0-CURRENT r360656.

If it only appears on 13.0-CURRENT, maybe there's a bug there?

Since this is a script only to be used by a maintainer (you) I'm much less worried than if this was something exposed to our users.

I will try to investigate better on the issue and then I will update the revision consistently with your wise suggestions. Indeed using basename is much simpler :) I should have thought about it.

I personally would keep this in the Makefile, but If you want to proceed with the script I am fine, too - after all you are the maintainer. ;-)

In either case, I believe we can simplify as per my comment from Sat, May 30, 22:54?

In D25042#552248, @salvadore wrote:

I think I found how to reproduce the bug on my machine:

Ah, that's helpful! Maybe a change (feature or bug) in make on -CURRENT?

[salvadore]

I committed the changes you proposed. Since you proposed them (and I tested them successfully) I considered them approved although I later noticed this review was marked as needing changes. I hope it is not a problem.

[gerald]

In D25042#553766, @salvadore wrote:

I committed the changes you proposed. Since you proposed them (and I tested them successfully) I considered them approved although I later noticed this review was marked as needing changes. I hope it is not a problem.

Sure, all good!