Could anyone please shed some light on why for linux we can’t also just do make update the first time around?
I presume it has to do with Linux versions where system libraries are to be prioritized. I still wonder though if we can do the classic “keep simple things simple, complex things possible”.
The documentation itself suggests that using system-library is part of the advanced setup. So I think this is something reasonable to ask.
Once again, great job and good luck squaring the remaining issues.
We could change it. Perhaps make update could set --use-linux-libraries, while running make_update.py directly would be the more advanced way to not get them?
This would need some adjustment for developers using system libraries, and maybe Linux distribution packages if they are using the make wrapper at all.
I think it would be better to keep it as is.
Mainly because you only need to opt-in for libraries once after a fresh clone.
Otherwise you need to make sure that you don’t run make update by mistake and ruin your setup.
I think people would be annoyed if we for some reason decided to do the reverse as well.
IE make update would force system libraries and you have to remember to instead run make_update.py to not ruin your setup.
I don’t think it is too much of a PITA to run a extra command after a fresh clone. Especially since it means that the workflow is the same between the different options.
One of the “features” of the Blender development environment is the easy of build. The work the Building team does here allows for one of the smoothest experiences I’ve ever seen.
If people want to disregard this and use the system libraries they can do so. But this should not get on the way of delivering a good experience to the recommended way of building Blender.
But this should not get on the way of delivering a good experience to the recommended way of building Blender.
Nor should it introduce any foot guns I feel.
Currently I test out our build system on multiple computers so I can test out if we break something depending if we do portable builds or system installs.
Currently I can just do a make update in all places and everything is fine.
If we introduce this I think there is only a matter of time before I type make update on the wrong computer and I have to catch that I messed up my setup.
I don’t see how having the user input ./build_files/utils/make_update.py --use-linux-libraries once will make the end user experience any worse IMO.
If you want the command to be less daunting, then I think we could have it as a make get_libs command
I haven’t checked up on the new system, but previously on windows, (where there is no system library), when the libs folder didn’t exist, it used to ask interactively if you wanted to download it or not, so it wouldn’t automatically unleash a 3-5GB download on unsuspecting people that perhaps are on a metered connection. Something like that could likely work here?
Hmm perhaps making it an explicit step on Mac and Windows would make sense as well then?
So after you cloned down the repo, you run make get_libs to get the libraries no matter what OS you are on? Then it is explicit that you will download a few gigs more. Only need to do it once as make update will take care of it after the first time. So it functions like it currently does in that regard.
Hi, I think we can acknowledge/determine that make update (and the vast part of your building tools) are intended for the workflow where we use binary libraries. Blender can still be built with system libraries (for now anyways), but it shouldn’t get on the way of the official supported way.
In practical terms that means:
We make make update behave the same in all platforms (aka, we change how it works in Linux now).
That means that anyone not using the binary libraries should not rely on make update since it will most likely mess up their setup. Use make code update instead.
System library developers coordinate a way to have their update workflow more centralized (as oppose to everyone having their own ad-hoc solution). I imagine this done by a separate script, similar to the install_deps.sh script. It can be part of Blender, and maintained by this group.
Alternative solutions are welcome, but they shouldn’t get on the way of the official supported way. Feedback is welcome.
I’m against this, this sort of thing always ends up affecting others maintaining the code or providing support. Just like what happened with install_deps.sh. I much prefer not changing anything over that.
I would very much like to know what this is supposed to mean? Especially the (for now anyways) part. I find it fairly critical to allow for our codebase to be built with common current versions of libraries.
That this support is not official (i.e., that the core team does not make particular efforts to ensure that this is always true, and guarantee some support in case it does not work anymore) is one thing.
But saying that we do not support at all building with system libraries (i.e. make it essentially impossible to build Blender without the massive pre-built libs) is something completely different, which I strongly hope is on no one’s radar.
Just like we have always welcomed patches allowing Blender to build on non-officially supported OS (BSD ones e.g.).
I also do not understand what that point is about? We already have install_linux_packages.py --all for that… there is nothing else needed here afaik, and maintenance of this tool is extremely low (unlike install_deps.sh case).
also do not understand what that point is about? We already have install_linux_packages.py --all for that…
Even better. In this case I think we are all good and don’t even need the (3).
I would very much like to know what this is supposed to mean? Especially the (for now anyways) part.
In the end I think you worded this better than I did. I also don’t think is in anyone’s radar to deliberately preventy system libraries from being used.
Given what Bastien mentioned regarding the install_linux_packages.py --all, does anyone in Linux object to making make update behaving in Linux the same as it does in Windows and Mac?
I still think we should keep it as it is.
I believe it is simpler to have make update only update folders that have been initialized (like it is now and what we do for tests etc).
As I’ve stated before, I think it would be better if we have a make command (that is not make update) that setup the libs.