On Fri, 2005-04-22 at 00:33 -0500, Chris Lattner wrote:> On Thu, 21 Apr 2005, Reid Spencer wrote: > > With Misha's changes requiring a total rebuild, I've been reminded how > > long the targets take to build. Now that there are more of them and in > > most cases I really don't care about n-1 of them, I'm wondering if its > > time to have configure allow optional compilation for them. > > > > I would like to suggest: > > > > 1. The default (build all targets) remains the same > > 2. We add to configure --disable-target-x86 to disable building the x86 > > target. Similarly for all other targets > > 3. We add to configure --disable-foreign-targets to disable all but the > > current host's target type. > > > > This will require a little bit of configure magic and some changes to > > the makefiles. > > Sounds great to me. I would suggest --disable-cross-targets instead of > --disable-foreign-targets though.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?> > -Chris >_______________________ Reid Spencer President & CTO eXtensible Systems, Inc. rspencer at x10sys.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050421/733ad792/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/20050421/733ad792/attachment.sig>
On Thu, 2005-04-21 at 23:58 -0700, Reid Spencer wrote:> On Fri, 2005-04-22 at 00:33 -0500, Chris Lattner wrote: > > On Thu, 21 Apr 2005, Reid Spencer wrote: > > > With Misha's changes requiring a total rebuild, I've been reminded how > > > long the targets take to build. Now that there are more of them and in > > > most cases I really don't care about n-1 of them, I'm wondering if its > > > time to have configure allow optional compilation for them. > > > > > > I would like to suggest: > > > > > > 1. The default (build all targets) remains the same > > > 2. We add to configure --disable-target-x86 to disable building the x86 > > > target. Similarly for all other targets > > > 3. We add to configure --disable-foreign-targets to disable all but the > > > current host's target type. > > > > > > This will require a little bit of configure magic and some changes to > > > the makefiles. > > > > Sounds great to me. I would suggest --disable-cross-targets instead of > > --disable-foreign-targets though. > > 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?-enable-targets=x86,alpha,sparcv9 -link-targets=alpha,host Valid options for both are: the names of the targets host all where all is the default for both items I have in my tree the patch to partially support this (well the link half of it). Right now I am controlling linking with a variable in the toplevel makefile until a config patch like this goes in. Andrew Lenharth http://www.lenharth.org/~andrewl/
On Thu, 2005-04-21 at 23:58 -0700, Reid Spencer wrote:> On Fri, 2005-04-22 at 00:33 -0500, Chris Lattner wrote: > > On Thu, 21 Apr 2005, Reid Spencer wrote: > > > With Misha's changes requiring a total rebuild, I've been reminded how > > > long the targets take to build. Now that there are more of them and in > > > most cases I really don't care about n-1 of them, I'm wondering if its > > > time to have configure allow optional compilation for them. > > > > > > I would like to suggest: > > > > > > 1. The default (build all targets) remains the same > > > 2. We add to configure --disable-target-x86 to disable building the x86 > > > target. Similarly for all other targets > > > 3. We add to configure --disable-foreign-targets to disable all but the > > > current host's target type. > > > > > > This will require a little bit of configure magic and some changes to > > > the makefiles. > > > > Sounds great to me. I would suggest --disable-cross-targets instead of > > --disable-foreign-targets though. > > 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. -- 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, 22 Apr 2005, Andrew Lenharth wrote:>> Does that make sense or do you have a better idea? > > -enable-targets=x86,alpha,sparcv9 > -link-targets=alpha,host > > Valid options for both are: > the names of the targets > host > all > > where all is the default for both items > > I have in my tree the patch to partially support this (well the link > half of it). Right now I am controlling linking with a variable in the > toplevel makefile until a config patch like this goes in.I think this makes the most sense. I assume that enabled-but-not-linked targets are built into shared objects? My one concern about this change is that it makes it more likely for people to break the build on hosts not equal to their own. However, as long as the nightly testers due the full build, I dpm t think this is a big problem. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
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 08:15 -0500, Andrew Lenharth wrote:> -enable-targets=x86,alpha,sparcv9 > -link-targets=alpha,host > > Valid options for both are: > the names of the targets > host > allAs others have agreed, this is a much better approach than the one I was thinking of. Its harder to parse in the configure script, but I can probably find a way to do it.> > where all is the default for both itemsThere 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. One other problem with making the default build only one or some of the targets is that it will (currently) cause the dejagnu tests to fail because llc won't know about certain targets that are in the test suite. Rei.d -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050422/4d4880c2/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/4d4880c2/attachment.sig>