To build xorg without rebuilding clang, Python, perl...

D

Daniel Tourde

Hello,

On FreeBSD 10.2 I try to build xorg with ports. I have an Intel GPU.
What drives me crazy is that it means installing Python, perl and a newer clang. It's just xorg we are talking about...

What do I need to do to avoid that (options? make.conf?)

Best regards

Daniel
 
You could just install the build dependencies (clang36, llvm36, python27, perl5) from the pre-built packages:
Code: 
pkg install clang36 llvm36 python27 perl5
 
Or install Xorg itself with binary packages. One of the advantages of building from ports is that even the build dependencies are built for the local system. Since compilers and interpreters do not change very often, and are usually used by more than one application, the build overhead is not as bad as it might seem.

Build dependencies are not recompiled every time a port needs them. They are only built when needed for the first time.
 
Thanks for your answers. I am fully aware of what you wrote. I just think that Clang36, Python and Perl should not be triggered. Xorg do not need these. I think Clang36, Python and Perl are triggered by Gallium. I have an Intel GPU, it does not use Gallium.... So no Gallium and KMS support and just Intel. How do I order port to build Xorg according to this?
 
I am trying to build as few packages as possible (and no, I don't want to install prebuilt binaries). So to be forced to build clang 3.6 when 3.4 is already there feels overkilled.
So, I replaced FreeBSD 10.2 by a current 11.0 (clang 3.7) in the hope I would skip the need to build an extra compiler. Well, I ways wrong... Clang 3.6 is still a hard depedency for xorg.

Well, all of this feels odd. Any possibility to skip 3.6? Any hope to get the build of xorg synchronized with the default compiler? From 3.4 to 3.6 I can possible understand
But from 3.7 to 3.6, I simply can't. It feels way too odd, to way the least.
 
Last edited by a moderator:
I am aware of that. I was hoping that the makefile would check the base compiler and adapt to the situation... IF clang < 3.6 install it, otherwise use the one provided by the system.
In any case, it feels odd to have 10.2 with clang 3.4, 11.0 with clang 3.7 and xorg (not a marginal code from a corner of the internet) requiring clang 3.6... Can't the makefile be adaptive, can't the base compiler be synchronized with the one required by gallium?
 
I think you can achieve your wish (where clang is concerned) by setting FAVORITE_COMPILER in make.conf(5). I was able to set GCC, using this. But I'm not sure if it will accommodate compiler versions. See; UNTESTED. ;)

Just thought I'd mention it. You might also ask on freebsd-hackers@. Or perhaps even better, freebsd-toolchain@

Good luck. :)

--Chris
 
Last edited by a moderator:
Daniel Tourde said:
I was hoping that the makefile would check the base compiler and adapt to the situation... IF clang < 3.6 install it, otherwise use the one provided by the system.
Click to expand...

Ideally, dependencies are never arbitrarily set, and the dependencies for a port are not determined by the port maintainers. The upstream developers declare a particular compiler a dependency for their build toolchain based on what compiler features that toolchain will use. Same for the base system: the version of Clang included with base is that needed to build FreeBSD, not the ports you want to install on top of FreeBSD. There are some instances of ports that include the option to use components included in base rather than building them from the ports tree, but those components aren't there to satisfy port dependencies. Should the versions of those components required by ports change before they're updated in base, the proper thing for the port maintainer (and user) to do would be to build the new version from the ports tree rather than try and force the older version to work.

In short, forcing a port to use a compiler other than the one the upstream developers say you need might be possible, but it's probably not a good idea. If it works, it's probably through shear serendipity, and even if it works now it almost certainly won't in the future.
 
You must log in or register to reply here.
Back
Top