[LLVMdev] Optional Target Builds

Al Stone ahs3 at fc.hp.com
Fri Apr 22 09:56:02 PDT 2005


On Fri, 2005-04-22 at 08:57 -0700, Reid Spencer wrote:
> 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?

That sounds good.  Like you said, it guarantees at least one
usable target.  Go for it :).

-- 
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
----------------------------------------------------------------------




More information about the llvm-dev mailing list