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



## Daniel Tourde (Dec 23, 2015)

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


----------



## ljboiler (Dec 23, 2015)

You could just install the build dependencies (clang36, llvm36, python27, perl5) from the pre-built packages:

```
pkg install clang36 llvm36 python27 perl5
```


----------



## wblock@ (Dec 23, 2015)

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.


----------



## Daniel Tourde (Dec 23, 2015)

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?


----------



## wblock@ (Dec 23, 2015)

There used to be a separate option for Gallium, but now it is built in, needed by libEGL.


----------



## Daniel Tourde (Dec 28, 2015)

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.


----------



## SirDice (Dec 28, 2015)

All versions of FreeBSD use the same ports tree.


----------



## Daniel Tourde (Dec 28, 2015)

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?


----------



## Chris_H (Jan 22, 2016)

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


----------



## ANOKNUSA (Jan 22, 2016)

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.



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.


----------

