Page MenuHome

Update install_deps.sh for ArchLinux
ClosedPublic

Authored by Ejner Fergo (ejnersan) on Apr 7 2016, 8:53 PM.

Details

Summary

The script is updated for ArchLinux, since all dependencies are included in Arch's official repositories.

I've made a few changes, such as enabling OCIO and OSD without requiring locally installed lib-path, and a fix to ''get_package_version_ARCH()' so it ignores package epoch (as in the case of ffmpeg).

I intend to look at OpenVDB next.

Diff Detail

Repository
rB Blender

Event Timeline

Ejner Fergo (ejnersan) retitled this revision from to Update install_deps.sh for ArchLinux.Apr 7 2016, 8:53 PM
Ejner Fergo (ejnersan) updated this object.
Ejner Fergo (ejnersan) updated this revision to Diff 6371.
Bastien Montagne (mont29) requested changes to this revision.

Generally patch looks good to me (cannot test it here, though ;) ).

Have a few points I do not understand/see why they were changed, see comments inlined.

build_files/build_environment/install_deps.sh
3458–3466

This change is bad and unneeded imho (it’s assuming WITH_NUMPY is always True).

3550

Why change this? version is very sensitive and important here.

3569

Why change this? version is very sensitive and important here.

3875

What’s the reason of removing 'g' global flag here?

This revision now requires changes to proceed.Apr 17 2016, 6:01 PM

Thanks for your comments, replied inline.

Regarding LLVM, as I have been continuing on updating the script for DEB and RPM distros, I've learned OSL is sensitive to this. As I understand it, OSL is the only thing needing LLVM in Blender, is that correct?

The OSL package in Arch's repo is compiled with a statically linked LLVM 3.5.2 [1] so in reality the version in line 3569 is irrelevant AFAICS, and only needed by the "WITH_CYCLES_OSL" cmake variable. Running 'ldd' on the blender binary shows no linking to LLVM, and rendering with the template OSL scripts works.

Continuing on LLVM, in my updated script for other distros I have set LLVM_VERSION(_MAX) = 3.5.2 and have succesfully compiled OSL and Blender on modernish DEB/RPM distros (gcc 4.7+) while having LLVM_VERSION_MIN = 3.4 for Ubuntu 12.04 and RHEL6. Is that out of the question? If not, I could also have Arch check for llvm35 instead of the default llvm (3.7), if someone wanted to force-build OSL on Arch.

I will update the diff after your reply.

PS: Are the 2 patches in install_deps_patches/ still relevant?

[1] https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/openshadinglanguage

build_files/build_environment/install_deps.sh
3458–3466

There is no "WITH_NUMPY" variable, causing python-numpy to never be installed in any case. Also by default "NUMPY_SKIP" is false. Doing it this way is consistent with DEB/RPM and it works.

3550

You are right, I'll revert this.

3569

See comment.

3875

If I didn't add this, these warnings appears:

gawk: cmd. line:1: (FILENAME=- FNR=1) warning: gensub: third argument <something> treated as 1

Regarding LLVM, as I have been continuing on updating the script for DEB and RPM distros, I've learned OSL is sensitive to this. As I understand it, OSL is the only thing needing LLVM in Blender, is that correct?
The OSL package in Arch's repo is compiled with a statically linked LLVM 3.5.2 [1] so in reality the version in line 3569 is irrelevant AFAICS, and only needed by the "WITH_CYCLES_OSL" cmake variable. Running 'ldd' on the blender binary shows no linking to LLVM, and rendering with the template OSL scripts works.
Continuing on LLVM, in my updated script for other distros I have set LLVM_VERSION(_MAX) = 3.5.2 and have succesfully compiled OSL and Blender on modernish DEB/RPM distros (gcc 4.7+) while having LLVM_VERSION_MIN = 3.4 for Ubuntu 12.04 and RHEL6. Is that out of the question? If not, I could also have Arch check for llvm35 instead of the default llvm (3.7), if someone wanted to force-build OSL on Arch.

So far, yes, llvm is only used by OSL (this may change in future). But the point of using clang package instead of llvm one as 'version check' is that I recently got cases of users having valid llvm version package, but without matching clang one (we need both).

As for the llvm/osl versions, please do not touch this! There are always many issues when updating those libs - known current one that prevents us to do it since months is that newer llvm/osl requires c++11, which is not yet officially enabled in Blender. But absolute main point is: this script must follow as close as possible blender releases, and stick to officially supported lib versions.

I’d also like to not try to support too much of those libs through distro packages (at least, until they get more mature). Trying to do so as proved to be rather hairy, with all the different versions and other crap from distro (ubuntu 2015.10 e.g. totally broke its own llvm/clang3.4 at first, because they did not rebuild those packages with new gcc5.x ABI…). This quickly turns into a blackhole time sink to maintain. :|

I will update the diff after your reply.
PS: Are the 2 patches in install_deps_patches/ still relevant?

Not sure, would say yes since we did not update libs, but you can try without them if you want ;)

[1] https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/openshadinglanguage

build_files/build_environment/install_deps.sh
3458–3466

You are right, sorry (probably a leftover from older code...).

3875

Uuuh… this is pretty suspicious, official gawk doc lists that "g" flag as supported... or maybe arch is using a new, not yet official release of gawk that changed that?

Ejner Fergo (ejnersan) updated this revision to Diff 6449.

Ok, made it so LLVM 3.4 and OSL always builds.

Also no force building of OpenCOLLADA, as Arch has a working version in repos. This won't affect other distros as they currently are set to compile no matter what.

Did some general cleanup as well.

Forgot to say, updated the llvm.patch since it was outdated. Don't know if it is critical though..

The osl.patch is also outdated, but I didn't touch that. I presume it is irrelevant since the patch doesn't get applied and there's no problem.

build_files/build_environment/install_deps.sh
3860

All I know is that the warnings are now suppressed, and DEB/RPM also has this "g"

This revision was automatically updated to reflect the committed changes.