sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: David Brown <dmlb2000 AT gmail.com>
- To: Eric Sandall <eric AT sandall.us>
- Cc: SM Discuss <sm-discuss AT lists.ibiblio.org>
- Subject: Re: [SM-Discuss] Arch Spec Changes
- Date: Mon, 23 Jan 2006 19:19:20 -0800
> Would there be two entries for the arch (e.g. pentium4 and
> pentium4-ricer) or just one pentium4 with the minimum
> (-march=pentium4) and then a separate menu for the additional archs?
> If the latter, the separate menu could be generated by adding an
> OPT_CFLAGS in the archspec file for the optional CFLAGS that we have
> removed from the minimal.
>
> e.g. for pentium4:
> CPUNAME="Intel Pentium IV"
> if use_gcc2; then
> CFLAGS="-march=i686"
> else
> CFLAGS="-march=pentium4 -mmmx -mfpmath=sse -msse -msse2"
> OPT_CFLAGS="-mmmx -mfpmath=sse -msse -msse2"
> fi
> HOST="i686-pc-linux-gnu"
> FAST="-O3"
> SMALL="-Os
>
> The optional archspec menu would the parse the space separated list of
> OPT_CFLAGS (if it exists) and have checkboxes for each. e.g.
> [ ] -mmmx
> [ ] -mfpmath=sse
> [ ] -msse
> [ ] -msse2
>
> Or we can just keep it simple (KISS) and have the minimal
> specifications in the archspecs and let the users use the custom
> CFLAGS area to add their own.
I was thinking on making two separate archspec files the extra menus
would need sorcery support and would be more work that I'd be willing
to do for it... unless Andrew really wants to see something like
this... then I'll probably be stuck implementing the menu system.
> Any way we do it I saw we only test our spells against the new minimal
> set of archspecs and if a bug comes up caused by custom archspecs we
> can put in code to remove them, but let users know that this is a
> courteousy and by no means required. :)
I agree on this I think gcc is a little smarter than us on figuring
out when to use what optimizations.
> What would we gain from setting the full explicit name rather than
> letting ./configure figure it out?
no since we pass x86_64-unknown-linux-gnu that's what ./configure uses.
./configure doesn't figure out anything it calls config.sub with that
argument to determin if the HOST valid, and if not complete make it
complete.
By passing x86_64-linux to config.sub it allows automake to figure out
what complete HOST to use and config.sub returns x86_64-pc-linux-gnu
instead of x86_64-unknown-linux-gnu
So I think it would be more complete to make HOST x86_64-pc-linux-gnu
for those arches. Since, making config.sub figure out what the full
HOST is returns x86_64-pc-linux-gnu.
The other option would be to throw out the 'completeness' of the HOST
and just make it x86_64-linux and let autotooled packages figure out
what HOST to use. This might be more perfereable for maintanence
reasons... less to fsck with in the future.
- David Brown
-
[SM-Discuss] Arch Spec Changes,
David Brown, 01/22/2006
-
Re: [SM-Discuss] Arch Spec Changes,
Eric Sandall, 01/23/2006
- Re: [SM-Discuss] Arch Spec Changes, David Brown, 01/23/2006
-
Re: [SM-Discuss] Arch Spec Changes,
Eric Sandall, 01/23/2006
Archive powered by MHonArc 2.6.24.