Bug 283504

Summary: www/vimb: Modify the Makefile
Product: Ports & Packages Reporter: mew14930xvi <mew14930xvi>
Component: Individual Port(s)Assignee: Zsolt Udvari <uzsolt>
Status: Closed FIXED    
Severity: Affects Only Me CC: uzsolt
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
URL: https://portsfallout.com/port/27207/
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284585
Attachments:
Description Flags
modify the Makefile mew14930xvi: maintainer-approval+

Description mew14930xvi 2024-12-23 07:18:42 UTC
Created attachment 256059 [details]
modify the Makefile

A build error was reported, so modify the Makefile.
Simplify USE_GNOME.
Switch post-patch: to patch file.
Comment 1 Zsolt Udvari freebsd_committer freebsd_triage 2024-12-26 20:01:11 UTC
I can build now. Could you please check again?
Comment 2 mew14930xvi 2024-12-27 01:01:03 UTC
It doesn't always fail.
In most cases it will be successful.
Comment 3 Zsolt Udvari freebsd_committer freebsd_triage 2024-12-27 13:22:26 UTC
(In reply to mew14930xvi from comment #2)
How can I reproduce it?
Comment 4 mew14930xvi 2024-12-27 13:29:55 UTC
I don't know.
If MAKE_JOBS_UNSAFE=yes, it should not fail.
Comment 5 Zsolt Udvari freebsd_committer freebsd_triage 2024-12-27 17:06:32 UTC
(In reply to mew14930xvi from comment #4)
Yes, maybe you've right.
As I see the default target is "all" which requires src.subdir-all (and version.h). The src.subdir-all target run "make -C src" and in src/Makefile exists main.o target which requires "../version.h". This src/Makefile doesn't know about Makefile and if the builder machine is "fast" (and parallel) the main.o target reached sooner (in src/Makefile) as version.h target.

So I think the "MAKE_JOBS_UNSAFE=yes" would be good solution.
Comment 6 mew14930xvi 2024-12-27 17:26:50 UTC
Anyway, the version is specified in the port's Makefile, so this is unnecessary processing.
It is worth modifying the Makefile even if the build is successful.
Comment 7 Zsolt Udvari freebsd_committer freebsd_triage 2024-12-27 17:43:03 UTC
(In reply to mew14930xvi from comment #6)
I agree your modification. I'm thinking: if you generate version.h from Makefile (with or without git) should add MAKE_JOBS_UNSAFE=yes too.

What do you think about create a version.h (in files/ with SUB_FILES and SUB_LIST [1]) and place it into WRKSRC (in post-patch target) and remove the version.h-rule from project's Makefile?

[1] https://docs.freebsd.org/en/books/porters-handbook/book/#using-sub-files
Comment 8 mew14930xvi 2024-12-27 17:59:51 UTC
I'll think about it if it fails frequently.
Comment 9 Zsolt Udvari freebsd_committer freebsd_triage 2024-12-27 18:11:18 UTC
(In reply to mew14930xvi from comment #8)
Okay. So do you want the actual patch with MAKE_JOBS_UNSAFE=yes?
Comment 10 mew14930xvi 2024-12-27 18:16:27 UTC
Since I became a maintainer, errors have been reported three times.
I'd like to see how it goes before adding MAKE_JOBS_UNSAFE=yes.
Comment 11 Zsolt Udvari freebsd_committer freebsd_triage 2024-12-27 18:35:41 UTC
Okay. Committed, thanks!
Comment 12 commit-hook freebsd_committer freebsd_triage 2024-12-27 18:36:18 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=043f51cb65ad079bc4c551a84689df0488d1a44c

commit 043f51cb65ad079bc4c551a84689df0488d1a44c
Author:     mew14930xvi <mew14930xvi@inbox.lv>
AuthorDate: 2024-12-27 18:31:05 +0000
Commit:     Zsolt Udvari <uzsolt@FreeBSD.org>
CommitDate: 2024-12-27 18:31:05 +0000

    www/vimb: Simplify generate version.h

    Sometimes build fails because of "slow" git-generating of version.h. If it
    isn't enough should add MAKE_JOBS_UNSAFE=yes.
    Remove cairo from USE_GNOME.
    Switch to patch file (instead of post-patch target).

    PR:             283504
    Approved by:    submitter is maintainer

 www/vimb/Makefile                    |  7 +------
 www/vimb/files/patch-Makefile (new)  | 15 +++++++++++++++
 www/vimb/files/patch-config.mk (new) | 23 +++++++++++++++++++++++
 3 files changed, 39 insertions(+), 6 deletions(-)
Comment 13 mew14930xvi 2024-12-27 18:39:57 UTC
Thanks.