Summary: | update graphics/blender to v4.1.1 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Shane <FreeBSD> | ||||||||||
Component: | Individual Port(s) | Assignee: | Vladimir Druzenko <vvd> | ||||||||||
Status: | Closed FIXED | ||||||||||||
Severity: | Affects Only Me | CC: | vvd | ||||||||||
Priority: | --- | ||||||||||||
Version: | Latest | ||||||||||||
Hardware: | Any | ||||||||||||
OS: | Any | ||||||||||||
URL: | https://developer.blender.org/docs/release_notes/4.1/ | ||||||||||||
Bug Depends on: | 277283, 279845, 279846 | ||||||||||||
Bug Blocks: | |||||||||||||
Attachments: |
|
Useful to update deps at same time, oiio, osl and openpgl 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
Why OPENCOLORIO_LIB_DEPENDS depends on libminizip.so:archivers/minizip ? 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. 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. (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. 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
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) (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. (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. Do you agree with me? Can I commit? Comment on attachment 251720 [details]
+ sort out Makefile
I'm ok with this
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(-) Thanks. |
Created attachment 251557 [details] maintainer update for graphics/blender Update graphics/blender to v4.1.1 re-sort to make portsclippy happy. I thought this was recently done but I am getting some more (from portfmt-1.1.5). add new options for CYCLES_ONEAPI, FRIBIDI and HARFBUZZ