Useful to update deps at same time, oiio, osl and openpgl

Comment 2 Vladimir Druzenko 2024-06-19 03:22:07 UTC

Try to insert Makefile.options into Makefile instead of:
.include "${.CURDIR}/Makefile.options"
and run portclippy.

portclippy gives me the same result from a makefile with options merged in at the location of the include

Created attachment 251566 [details]
maintainer update for graphics/blender

I seem to have acquired a habit of looking at wrong files.

Here is an updated patch re-arranged to make portclippy happy when Makefile.options content is merged into main Makefile

Comment 5 Vladimir Druzenko 2024-06-19 12:59:54 UTC

Why OPENCOLORIO_LIB_DEPENDS depends on libminizip.so:archivers/minizip ?

Comment 6 Vladimir Druzenko 2024-06-20 02:49:55 UTC

Is llvm:max=15 still required?

stage-qa reports it as linked with no dep, ocio is the only place I see it used

(In reply to Vladimir Druzenko from comment #6)
I have not experimented with blenders use of llvm yet. If osl is enabled blender will need to use the same llvm version as used in the osl libs.

Comment 9 Vladimir Druzenko 2024-06-25 22:46:28 UTC

Do you know what the WITH_LLVM and WITH_CLANG cmake options are for?
What do they really change?
Look like blender build and work fine with LLVM from base (with CMAKE_ARGS=-DCMAKE_CXX_STANDARD:INTEGER=17).
But if it work faster or have advanced functions then we can force build it with LLVM from ports.

(In reply to Vladimir Druzenko from comment #9)

I haven't looked into it much, I can't grep any conditional use of WITH_LLVM or WITH_CLANG within cmake files. I think the ASAN option uses clang.

I know they use clang-tidy to reformat code.

I know there are cuda modules in cycles (which aren't going to be helpful on FreeBSD) and areas with gpu acceleration being added, compositor etc. which may use alternate cpu targets. Although I think the gpu acceleration is done through opengl or vulkan.

Comment 11 Vladimir Druzenko 2024-06-26 11:59:43 UTC

(In reply to Shane from comment #10)
What do you think should we turn on WITH_LLVM and WITH_CLANG mandatory (use LLVM from ports: USES=llvm) or better use LLVM from base?
Or only if CYCLES_OSL is on (graphics/openshadinglanguage require LLVM from ports)?
Anyway we can build blender with LLVM from base, but openshadinglanguage with LLVM from ports.

Comment 12 Vladimir Druzenko 2024-06-26 12:27:17 UTC

Also blender can't detect minizip-ng, but can minizip. But it have "build_files/build_environment/cmake/minizipng.cmake" file…
I'll keep the old minizip unless we can do something about it.

(In reply to Vladimir Druzenko from comment #12)

blender will link to both minizip and minizip-ng, OPENCOLORIO controls the link to minizip. 

I have seen the link to minizip-ng and no option seems to change that, so it should go into LIB_DEPENDS. It was added for 3.5, but so far I think it has been pulled in indirectly.


(In reply to Vladimir Druzenko from comment #11)

For now, I see no issue turning on WITH_LLVM and WITH_CLANG, as using base llvm will prevent extra deps. When this clashes with the osl llvm, we can sort it out then.

Created attachment 251719 [details]
maintainer update for graphics/blender

update patch with minizip-ng dep as well as enabling WITH_LLVM and WITH_CLANG

Comment 15 Vladimir Druzenko 2024-06-27 11:15:33 UTC

Created attachment 251720 [details]
+ sort out Makefile

(In reply to Shane from comment #13)
> blender will link to both minizip and minizip-ng, OPENCOLORIO controls the link to minizip. 
> I have seen the link to minizip-ng and no option seems to change that, so it should go into LIB_DEPENDS. It was added for 3.5, but so far I think it has been pulled in indirectly.
I saw only one time it linked with minizip-ng - after I add LDFLAGS+=-lminizip-ng.
You can check:
readelf -d /usr/local/bin/blender-bin | grep zip
readelf -d /usr/local/bin/blender-thumbnailer | grep zip
readelf -d /usr/local/lib/python3.11/site-packages/libextern_draco.so | grep zip

But graphics/opencolorio always linked with minizip-ng:
readelf -d /usr/local/lib/libOpenColorIO.so.2.3|grep zip
 0x0000000000000001 NEEDED               Shared library: [libminizip-ng.so.1]

I've always used ldd to check libs

% ldd /usr/local/bin/blender-bin | grep zip
        libminizip.so.1 => /usr/local/lib/libminizip.so.1 (0x34bc0a5b1000)
        libminizip-ng.so.1 => /usr/local/lib/../lib/libminizip-ng.so.1 (0x34bc52be5000)


a blender build with ocio off still shows

% ldd stage/usr/local/bin/blender-bin | grep zip
	libminizip-ng.so.1 => /usr/local/lib/../lib/libminizip-ng.so.1 (0x14d4a8180000)

Comment 17 Vladimir Druzenko 2024-06-28 11:41:01 UTC

(In reply to Shane from comment #16)
"ldd" show transitive dependencies too.
"readelf -d" show direct dependencies only.

"poudriere testport" use "readelf -d" to check real dependencies and show mistakes.

(In reply to Vladimir Druzenko from comment #17)
ok then.

As long as it runs when it isn't installed, I don't mind either way. It's your call if you want minizip-ng as mandatory, you can move it to USES if you want to keep it.

Comment 19 Vladimir Druzenko 2024-06-29 10:52:09 UTC

(In reply to Shane from comment #18)
It does not link to minizip-ng under any circumstances and I don't think we should fix that as part of port maintaining.
But it links to minizip when built with WITH_OPENCOLORIO.
So I would leave it like this (in last patch):
OPENCOLORIO_USES=               minizip
Without any dependencices from minizip-ng.

Comment 20 Vladimir Druzenko 2024-07-01 14:21:33 UTC

Do you agree with me?
Can I commit?

Comment on attachment 251720 [details]
+ sort out Makefile

I'm ok with this

Comment 22 commit-hook 2024-07-02 13:25:52 UTC

A commit in branch main references this bug:

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

commit ee72976e375a2daa4517ac56853177cdef161b8a
Author:     Shane <FreeBSD@ShaneWare.Biz>
AuthorDate: 2024-07-02 13:23:24 +0000
Commit:     Vladimir Druzenko <vvd@FreeBSD.org>
CommitDate: 2024-07-02 13:23:24 +0000

    graphics/blender: update 4.0.2 → 4.1.1

    Changelog:
    https://developer.blender.org/docs/release_notes/4.1/

    PR:     279847

 graphics/blender/Makefile                          | 46 ++++++++++++----------
 graphics/blender/Makefile.options                  | 17 ++++++--
 graphics/blender/Makefile.versions                 |  4 +-
 graphics/blender/distinfo                          |  6 +--
 ...-intern_cycles_kernel_osl_CMakeLists.txt (gone) | 10 -----
 graphics/blender/pkg-plist                         | 35 ++++++++--------
 6 files changed, 62 insertions(+), 56 deletions(-)

Comment 23 Vladimir Druzenko 2024-07-04 10:29:23 UTC

Thanks.