Photo example of FreeBSD Ports. Re: graphics/blender

sidetone

sidetone

2022-06-02-082012_2560x800_scrot.png

Here is an example of a single FreeBSD port in 3 terminals in the screenshot. The ncurses menu on the left shows the menu after make config is run from the port directory. You can see the graphics/blender directory and a few files, including the Makefile in the top right terminal. In the bottom right terminal, there's contents of a Makefile, which can be seen by using the less command. There's more, because there's 2 other Makefiles which are part of the main Makefile, but they're all covered by the command that shows the menu on the left.

There's more options and dependencies not shown from two of the terminals, because it all doesn't fit on the screen. To see more, try the commands, and scroll down. The terminal on the top right shows the port directory and it's contents, where Makefiles and other important porting files are listed.

The Makefile shows the version number that it seeks to download, and it shows official compressed source file download site of blender.org and its identical mirrors.

To get the screen on the left, type make config. To set that and all of the dependencies of it, type make config-recursive.

Running make; make install will download these and all of its dependencies' compressed source files, then build and install them all according to required dependencies plus the selected choices.

For users to choose what they want, those are the options and a showing of commands to install it from source which are simple to use. In this example, 3.1.2 is the latest stable release from Blender.


To get a newer version, making a new directory with similar files can be adjusted to do that, and add other options, that the user can choose from to build is a more complex task for a new Makefile and Port directory. That requires the Porter's Handbook. Other BSD's and Gentoo Linux also use a ports system. Ports isn't packages, but ports builds custom user packages.

Something as demanding as a nightly install will require maintainership from the organization that develops the software, because that would be a daunting endless task for a volunteer. The existing port of Blender is exceptional and well maintained.
 
Just why? This unholy thread was "done" after very few posts with a simple result: A port of blender exists, is up to date and isn't overly complex (just supports a lot of build-time options). It does include a few patches, really not much, would sure be nice to have them "upstreamed", but you don't really need extra developers for that ... end of story.

Then there's this practice of offering builds that bundle tons of dependencies. It seems more and more Linux users like that flawed idea. We've seen most FreeBSD users don't, for good reasons. So, anyone can do what they want, but it's very unlikely to find anyone here helping blender to do this for FreeBSD. IMHO, no need to continue talking about it...
 
The example I posted is an example that FreeBSD ports covers everything available. Anything more, that an updated Port/Makefile can't cover is a perpetual dependency and configuration hell. If it needed the latest, then let the organization maintain it.

As I was saying, the latest stable one in ports is great. It has so many options to choose from. How many are needed?

The thread can be locked at some time, I was thinking of suggesting that it be locked in opening post, but see no harm in it continuing. Until it gets like it did in the last thread.

People need to see this, so they can see by example what BSD ports are. They don't get it. They need a well rounded picture, and a description under it.

Wanting more than what can be added by a maintainer, either volunteer or from the official program, isn't needed. If something is not current to the latest stable port, or if something is lacking, then, fine, as long as it's actually a useful feature, and not just some "said" but useless so called feature. Doing much more than that what Ports can offer would be like inspecting every anthill in a square mile, for little gain.

I get that Samba on FreeBSD is actually an old version, that fails to interact with other SMB filesystems. The issue was updating it, not the system of Makefiles itself. Maybe the system can be improved, but not the fundamental ideals of Makefiles. Ok, you have NFS, so you don't need Samba.

I don't understand what else there is to offer that something like Ports/Makefiles already can do. Anything more wouldn't achieve a purpose. Sure, the infrastructure could be improved, but adding countless ways to make something that doesn't add to functionality isn't one of them. Gentoo compares to what BSD ports do, and anyone trying that is going to get a headache.

At least I hope informational posts and neutral posts are preserved, but this sums up a lot of it.

People need to see a picture, to know what Ports/Makefiles are. And how that can cover everything, provided it's available.
 
sidetone said:
The thread can be locked at some time, I was thinking of suggesting that it be locked in opening post, but see no harm in it continuing. Until it gets like it did in the last thread.
Click to expand...
It could save our mods a lot of work, if OPs could lock their initialized threads themselves. Isn't it, SirDice ?

OPs usually have a fine tuned sense when their thread had it's purpose.
A "enough-is-enough-feeling" always is a brilliant hint for posing a lock.

Folks, no joke. The "solved" label should include a lock also. This would prevent even forum archeologists from making year old threads zombies again.
 
It would be abused, unless it could be locked only after the beginning post. I didn't need ask to have it locked either. Something like that needs to be shown for informational purposes, with a picture. Someone could add to it. And some useful opinions/words were added.

Maybe how-to/faq, but this is too short and less of a how-to/faq. It would need to be better and better thought out than this. But it's the basics.

If a Windows/Linux user doesn't understand ports, I'll link to this thread.

Some things can be added to a solved thread. Maybe autolock those after a month or year. Threads over a year old should have an automatic waiver on them, saying those are older threads with the age or date highlighted.
 
Ah... now I feel like complete sh*t. I was opening a private conversation with him yesterday for the collaborating of developing the Blender fork (UPBGE) port... but I didn't get back with him soon enough.

I was busy trying to rebuild my packages through Poudriere since my original batch with it got easily wiped out from a normal pkg clean and I was too tired after that.

From logging in just now and looking into said conversation, he deleted his account as well...
 
The person is free to try whatever. They chose to leave, and had changed the thread title to saying FreeBSD was unsuitable and archaic before doing so. They may get disappointed that most Linux distributions don't have something like ports.

The Stable port looks good, and it was recently updated. People can focus on improving, trying and testing that. The only way I see an unstable newer version coming here is if Blender maintains that nightly build, and nothing major depends on it. There's no reason, they can't maintain and contribute to other ports which are dependencies.

If anyone wants, they can look at the screenshot, and figure out how to see the rest of the options, or dependencies. How to build it with different compilers/makes etc.

Also, maybe porting https://upbge.org/#/, if there's enough interest in it.
 
I have part of that Makefile in the screenshot above, but a link helps people see the rest of it, without using their FreeBSD computer. There's 3 makefiles. As anyone can see from the Makefile, the chosen make is set to cmake, and the compiler version is chosen.

Actually, the nightmare is that there's a whole lot of dependencies and options. How they're handled looks very crisp. I don't know much about Makefiles, but I can tell that's a good structure, and has everything efficient to needs. That Makefile goes directly to the dependency and options needs, and doesn't mess around outside of that.

Here's a screenshot of Blender 3.1.2. The version number is in the box with the graphic in the middle of the screen on the top right side. When clicking on about, it uses a console webbrowser in the terminal emulator.
blender.jpg

pkg info blender:
Code: 
blender-3.1.2
Name           : blender
Version        : 3.1.2
Installed on   : Thu Jun  2 11:29:56 2022 CDT
Origin         : graphics/blender
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : graphics multimedia
Licenses       : GPLv3+
Maintainer     : FreeBSD@Shaneware.biz
WWW            : https://www.blender.org/
Comment        : 3D modeling/rendering/animation package
Options        :
    ALEMBIC        : on
    ALEMBIC_HDF5   : on
    AVI            : on
    BULLET         : on
    CAMERATRACK    : on
    CINEON         : on
    COLLADA        : on
    COMPOSITOR     : on
    CYCLES         : on
    CYCLESEMBR     : on
    CYCLESOSL      : off
    DDS            : on
    DRACO          : on
    EBOOL          : on
    FFMPEG         : on
    FFTW3          : on
    FRAMESERVER    : on
    FREESTYLE      : on
    HARU           : on
    HDR            : on
    HEADLESS       : off
    INPUT_NDOF     : on
    JACK           : off
    LZMA           : on
    LZO            : on
    MENU           : on
    MOD_BOOLEAN    : on
    MOD_FLUID      : on
    MOD_OCEANSIM   : on
    MOD_REMESH     : on
    MOD_SMOKE      : on
    NLS            : on
    OPENAL         : on
    OPENCOLORIO    : on
    OPENEXR        : on
    OPENIMAGEDN    : on
    OPENIMAGEIO    : on
    OPENJPEG       : on
    OPENMP         : off
    OPENSUBDIV     : on
    OPENVDB        : on
    PUGIXML        : on
    PULSEAUDIO     : on
    QUADRIFLOW     : on
    RAYOPTIMIZATION: on
    SDL            : on
    SNDFILE        : off
    TBB            : on
    THUMBNAILER    : on
    TIFF           : on
    TRACE          : on
    XF86VMODE      : on
    XINPUT         : on
Shared Libs required:
    libOpenImageDenoise.so.1
    libavutil.so.56
    libexpat.so.1
    libOpenImageIO.so.2.3
    libjpeg.so.8
    libfreetype.so.6
    libyaml-cpp.so.0
    libgmpxx.so.4
    libglog.so.1
    libOpenCOLLADABaseUtils.so
    libflite_usenglish.so.1
    libboost_thread.so.1.79.0
    libAlembic.so.1.8
    libpython3.10.so.1.0
    libtiff.so.5
    libembree3.so.3
    libzstd.so.1
    libavfilter.so.7
    libXrender.so.1
    libIlmThread-3_1.so.30
    libosdGPU.so.3.4.4
    libboost_regex.so.1.79.0
    libosdCPU.so.3.4.4
    libOpenCOLLADAFramework.so
    libswscale.so.5
    libflite_cmu_us_kal.so.1
    libXxf86vm.so.1
    libavformat.so.58
    libXi.so.6
    libblosc.so.1
    libOpenCOLLADASaxFrameworkLoader.so
    libpugixml.so.1
    libpcre.so.1
    libfftw3.so.3
    libftoa.so
    libOpenImageIO_Util.so.2.3
    libOpenEXRCore-3_1.so.30
    libswresample.so.3
    libflite_cmulex.so.1
    libOpenEXR-3_1.so.30
    libpystring.so.0
    libxml2.so.2
    libopenal.so.1
    libtbb.so.12
    libOpenCOLLADAStreamWriter.so
    libavdevice.so.58
    libXfixes.so.3
    libboost_locale.so.1.79.0
    libboost_date_time.so.1.79.0
    libavcodec.so.58
    libGL.so.1
    libbuffer.so
    libgmp.so.10
    libboost_chrono.so.1.79.0
    libpotrace.so.0
    libMathMLSolver.so
    libX11.so.6
    libImath-3_1.so.29
    libIex-3_1.so.30
    libboost_iostreams.so.1.79.0
    libpng16.so.16
    libopenvdb.so.9.0
    libboost_filesystem.so.1.79.0
    libboost_system.so.1.79.0
    libopenjp2.so.7
    libboost_atomic.so.1.79.0
    libOpenColorIO.so.2.1
    libGeneratedSaxParser.so
    libUTF.so
    libflite.so.1
Shared Libs provided:
    libextern_draco.so
Annotations    :
    FreeBSD_version: 1300139
    cpe            : cpe:2.3:a:blender:blender:3.1.2:::::freebsd13:x64
Flat size      : 174MiB
Description    :
Blender is a free and fully functional 3D
modeling/rendering/animation/gaming package.

WWW: https://www.blender.org/
That port was built into a custom package. Those are the options that can be set easily by the user, which doesn't require specialized knowledge, because the Makefile is made that way. It shows dependencies as well. If the source code allows for another option that's available, or there's an adjusted dependency the Makefile can be accommodated for that.

That's how FreeBSD Ports work. For clarification, Ports are built from source code that was downloaded and uncompressed originating from official repositories and mirrors. Use it, or don't, but that's what it is.

Building source from a structure that doesn't use a Makefile may mean inconsistent results, and repeated excessive work each time. Ports/Makefiles provide for a consistent and repeatable way to download compressed tar files, uncompress them, and build them from source. It's so all a user has to do is go to the port directory and enter simple commands, or use their favorite port management tool. A combination of pre-downloaded packages and ports can be used too, but that's another story.
 
Seeing the amount of configurable build options a user has at their disposal with graphics/blender, trying to create the port for UPBGE would've been a great deal waste of time for me. In addition, I might've had to deal with more required dependencies that could've lead to greater pain with a dependency hell of many dependencies. The next reason I wanted to help that person was that I was a bit empathethic about him "looking through tons of documentation" and not getting anywhere with it. But considering how new I am to making ports, I would've been biting more than what I can chew. I need to take baby steps getting more familiar with the Makefiles and their ports syntax/configuration.

Perhaps he could've got a custom Blender package to build for ARM64 if he experimented with disabling the right build options that were more AMD64 specific.
 
sidetone said:
Actually, the nightmare is that there' s a whole lot of dependencies and options. How they're handled looks very crisp. I don't know much about Makefiles, but I can tell that's a good structure, and has everything efficient to needs. That Makefile goes directly to the dependency and options needs, and doesn't mess around outside of that.
Click to expand...
I was also impressed with how neat and well-organized those makefiles are, especially considering the huge number of options and dependencies.
stratact said:
From logging in just now and looking into said conversation, he deleted his account as well...
Click to expand...
That's a bummer. I thought his half-ass render farm was kind of cool (I have a thing for throwing together systems from old and unused hardware). The render he made was cool, too.
 
A relevant question now is, of all those options which can be set, what's missing from the Makefile? Also, which dependencies for those options are needed, and are they in Ports? For the stable/production version of Blender 3.1.2, of course. Finding that, may take grep-ing through the sourcecode. If it's an overly Linuxism dependency that offers no real feature, or a systemd like dependency, it's useless and we don't need it.

For a nightly version, that's a different story, and let Blender maintain such a thing, if there's enough reason due to of there are feature-ful options and dependencies. If someone really needed something, they could copy and hack that Makefile to a user custom port.

If anyone is serious about options on Blender, now this is getting somewhere. If these examples, descriptions and discussions don't help, then, this may not be their thing. Though, regardless of a state of a Ports system, there's no better ideal for building from source than a Makefile based compiling system. That's also a well written Makefile.


That person did a lot of work, but took so much information at once, that they didn't understand it. They were forcing something through that didn't make sense, and wouldn't work as well as this Port/Makefile system. It was also vague about which features. Options are listed there now clear to see for a good modern stable and well written port, so if anything is wanted, compare it to that, and see if it's an actual useful feature or some meaningless Linuxism.
 
grahamperrin@ said:
Who?

triguy, maybe?
Click to expand...
The guy who left the forums. He wanted the developers to maintain a port also of the unstable version, kept trying git, and kept saying he wanted "features". There was a lot of failure to communicate. First he said how FreeBSD was cool, and liked it so much. After a few days, he got mad, and said FreeBSD was archaic and the ports were an outdated novelty. He changed the title to say something like that, then the thread got canned, so I started this thread to explain what ports are. Those are a lot of features, I showed in pictures, so I don't know what more features he wanted.

No one remembers the name. I don't know if he changed it, or I'm not sure if he deleted his name himself, or if a mod did that.

He pointed out that Samba was outdated and didn't have the newer features to use with other computers with Samba. He said he was paid to do some project. The person did a lot of work, but was trying to apply Linux and Git instructions to FreeBSD. Then, we couldn't explain what ports were, and he kept bringing up git. That was going to be my response, but he left, so I wrote it anyway. The person was applying the wrong instructions to the wrong things, by trying to pick up so much at once.

It was a new guy, I don't think it was triguy, who had the Japanese style avatar. That person is still here, I believe.
 
sidetone said:
and the ports were an outdated novelty.
Click to expand...
Even after we demonstrated to him that our Blender port was completely up to date with upstream.

But I fear we will get more and more types like this. Once the Linux communities have regressed to a point, they will start to gravitate onto this forum as the first "low effort" point of contact. The admins have their work cut out for them!
 
You must log in or register to reply here.
Back
Top