On Fri, 22 Apr 2005, Al Stone wrote:>> Actually, the options have to be expressed as "enable-something" so >> I've opted for "--enable-target-this" to enable just the $host target. >> if you specify --disable-target-this (the default) then you get >> whatever platforms you specify with --enable-target-{targetname} >> >> Does that make sense or do you have a better idea? > > What I would prefer (for what that's worth) is that by default, > only the host target is enabled. That will speed up my builds > a bit and keep sizes a bit smaller. If I then had an option so > I could do something like '--enable-arch=ppc,x86_64,ia64', I > could build whatever cross-targets I wanted for a particular > package.Would passing one option, "--enable-arch=host", be ok? -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
On Fri, 2005-04-22 at 10:18 -0500, Chris Lattner wrote:> On Fri, 22 Apr 2005, Al Stone wrote: > >> Actually, the options have to be expressed as "enable-something" so > >> I've opted for "--enable-target-this" to enable just the $host target. > >> if you specify --disable-target-this (the default) then you get > >> whatever platforms you specify with --enable-target-{targetname} > >> > >> Does that make sense or do you have a better idea? > > > > What I would prefer (for what that's worth) is that by default, > > only the host target is enabled. That will speed up my builds > > a bit and keep sizes a bit smaller. If I then had an option so > > I could do something like '--enable-arch=ppc,x86_64,ia64', I > > could build whatever cross-targets I wanted for a particular > > package. > > Would passing one option, "--enable-arch=host", be ok?If what you mean is that "--enable-arch=host" would build only the host target, that could work. "--enable-arch=host-only" or something _might_ be clearer. So let me see if I can paraphrase: the proposal is to add a new configure option to the build, "--enable-arch" (or "--enable-target" -- either works for me). One can provide comma separated parameters to "--enable-arch" as follows: -- "all": the default, which builds all targets, regardless of the host for the build -- "host" (or "host-only"): build only the code generators for the current build host -- "c", "x86", "ppc", ... : build only the code generators for the named targets (hmm, maybe '--enable-target' is better..). If that's what you meant, it sounds good to me... but I reckon Reid gets to have a say, too :). -- Ciao, al ---------------------------------------------------------------------- Al Stone Alter Ego: Open Source and Linux R&D Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: ahs3 at fc.hp.com ahs3 at debian.org ----------------------------------------------------------------------
On Fri, 2005-04-22 at 09:52 -0600, Al Stone wrote:> On Fri, 2005-04-22 at 10:18 -0500, Chris Lattner wrote: > > Would passing one option, "--enable-arch=host", be ok? > > If what you mean is that "--enable-arch=host" would build only the > host target, that could work. "--enable-arch=host-only" or something > _might_ be clearer. So let me see if I can paraphrase: the proposal > is to add a new configure option to the build, "--enable-arch" (or > "--enable-target" -- either works for me). One can provide comma > separated parameters to "--enable-arch" as follows: > > -- "all": the default, which builds all targets, regardless of > the host for the build > -- "host" (or "host-only"): build only the code generators for > the current build host > -- "c", "x86", "ppc", ... : build only the code generators for the > named targets (hmm, maybe '--enable-target' is better..). > > If that's what you meant, it sounds good to me... but I reckon > Reid gets to have a say, too :).Yeah, that's pretty much exactly it, with one exception. I was planning to *always* build the CBackend and Skeleton targets. Both are pretty fast to build and it gives LLVM *some* kind of target to fall back on. Given that, we might also want to have an option for "none" so that no processor targets are built, just the CBackend and Skeleton. Thoughts? Reid -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050422/679068eb/attachment.html> -------------- 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/679068eb/attachment.sig>