On Fri, 2005-04-22 at 11:39 -0500, Misha Brukman wrote:> On Fri, Apr 22, 2005 at 08:54:07AM -0700, Reid Spencer wrote: > > There has been some debate about the default value. I tend to agree > > with Chris on this. The default should be "all" so that everything > > gets tested by default. More sophisticated users can limit the targets > > that are built by merely typing -enable-targets=host on the configure > > line; not a big deal in my books. > > I would claim that from a user's perspective, default should be a > compiler that generates code for the host platform, and nothing else. > As we gather more and more backends, the "default" compilation will take > longer and longer. > > A developer who wishes to make sure none of his changes break other > targets and the nightly tester should run with `--enable-targets=all', > but it doesn't make sense (to me) to make it the default. >Okay, we need to get this resolved. So far we have two camps: (a) those that want the default to be "all" and (b) those that want the default to be "host-only". This is easy enough to change in the configure script; we just need to make a decision. So far we have: (a) - Reid, Chris, Andrew Lenharth (b) - Misha, Vikram, Al Stone Since we're split down the middle (including the Oversight committee), I'm not sure which way to go. Anyone want to change their vote? Any other voters? Any other way to resolve this? Reid -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050422/506eaee7/attachment.sig>
> Okay, we need to get this resolved. So far we have two camps: (a) those > that want the default to be "all" and (b) those that want the default to > be "host-only". This is easy enough to change in the configure script; > we just need to make a decision. So far we have: > > (a) - Reid, Chris, Andrew LenharthI vote for A because at this stage LLVM is primarily used by developers and with all the changes made.. its good to have it set by default to compile everything, and run tests for all targets. Not everyone really checks the nightly-tester (ie. how many notice the sparc test failures or even care?). Now if someone is working on a specific backend where changes do not impact other targets, they can easily configure to only compile that one target. I think this subject should be revisited when llvm becomes more mainstream. -Tanya
Okay, Tanya and Markus tipped the decision over to option (a), build all
targets. However, I think Tanya hit it right on the money: this needs to
be revisited when the "activity community" is more users than
developers.
The feature is now implemented in the CVS head. If you do nothing you
shouldn't experience any changes as the default is the same as before
the feature was implemented.
To use the feature, the option to configure is --enable-targets={value}.
Valid values are:
all: build all targets
host-only: build only the target for the host you're building on
list: comma separated list with specific targets selected from
alpha,ia64,powerpc,skeleton,sparc,x86,x86_64
Note that for now, x86_64 and x86 are the same. They both enable
building the lib/Target/X86 directory.
I would appreciate it if, on the next reconfigure, people using PowerPC,
Sparc, IA64 and Alpha would test this feature out. In particular, please
validate that:
The default is "all", "host-only" gets your platform
correct, and some
combination of specific targets works correctly.
Thanks for all the feedback and lively debate on this.
Reid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050422/c559aea7/attachment.sig>
On Fri, 22 Apr 2005, Reid Spencer wrote:> Okay, we need to get this resolved. So far we have two camps: (a) those > that want the default to be "all" and (b) those that want the default to > be "host-only". This is easy enough to change in the configure script; > we just need to make a decision. So far we have:Let me try to clarify why I feel the way I do. For this discussion, I use the term "end-user" to be someone who just wants to USE a compiler, and doesn't want to hack on the compiler. To me, the current LLVM distro isn't something that an end-user would generally want to use directly. In particular, the LLVM CVS repo is currently biased towards supporting developers more than end-users. For end-users, I think it would be most useful to build all of the targets, but only link the host target into llc (the others remain as .so files). That way the common case of non-cross-compiling will be fast (llc has a smaller disk footprint), but cross compilation can still work. Since end users don't build the tree often (e.g. only once), they don't really care THAT much about LLVM build time. More commonly, a packager will do this work for them, producing a set of debs, gentoo packages, etc. The problem with building targets as .so files is transparency: you need to know to pass "-load libfoo.so" to llc to get support for the "foo" target. In the long-term, I think this is 100% acceptable. In particular, llc is a low-level developer tool that end-users will ideally not have to directly use in the future. In particular, someday hopefully soon, end-users will interface to the llvm toolchain exclusively through the llvmc tool. llvmc will fork off the subtools when necessary. I think it's perfectly reasonable for llvmc to know which targets are linked into the llc tool and automatically provide the -load option when needed. If you accept the above, then we have 3 classes of people to consider: 1. end-users with the above definition, 2. developers that want to test everything [including the nightly testers], and 3. developers who don't want to test everything. I think that all groups of people are important, the only question is who passes the extra flag. I think that "punishing" group #3 is the right way to go, because they're the ones that want to do something strange, and they're the ones that know enough about llvm to do it. :) -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/