[LLVMdev] Default build options

[Alp Toker]

On 27/01/2014 01:31, Vaibhav Bedia wrote:
> Hi,
>
> I have just started off exploring LLVM usage for a class that i am taking.
>
> I cloned the git repos and spent about a day trying to get a working 
> setup.
> A large part of the time went in figuring out how to get a minimal 
> config working.
>
> I noticed that by default LLVM builds for multiple architectures (in 
> debug mode!)
> and there are config options to do host-only release build. When i 
> started off i kept
> on getting link time errors due to lack of memory.
>
> After a few cycles which involved increasing the memory allocated to 
> the VM instance
> then increasing swap space and then creating a new VM with more disk 
> space (15GB
> of free space for LLVM wasn't sufficient!) i am wondering why the 
> defaults are set the
> way they are.

LLVM's build-time requirements are on the very low end of what modern 
software projects require. Compare and contrast with other projects of 
similar size like WebKit or Boost.

It's only to be expected that if you use a machine with pre-millennium 
specifications it's going to struggle to keep up. Same thing applies if 
you try to run modern computer games or word processors on a PC from the 
90s.

>
> Do most of the users really care about arm, cpp, hexagon, mips, 
> mipsel, msp430,
> powerpc, ptx, sparc, spu, systemz, x86, x86_64 and xcore at the same time?
> Shouldn't enabling of more architectures be left to the power-users?

One of the design goals of LLVM is to inherently support 
cross-compilation so there's no reason to assume the host architecture 
is the one the user wants.

We've found that disabling features by default when they're not widely 
used actually increases the maintenance burden because issues don't get 
reported.

I'd usually recommend disabling unused backends with the documented 
configure options. If however you're taking a class you really want to 
have those backends for context.

So I suspect the necessary hardware would have been cheaper than the 
time it took to write this email thread..

Alp.

-- 
http://www.nuanti.com
the browser experts