Skip to Content.
Sympa Menu

sm-discuss - Re[2]: [SM-Discuss] GCC Targets

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Mark Andrews <msasgl AT msa-enterprises.com>
  • To: Ryan Abrams <rabrams AT sourcemage.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re[2]: [SM-Discuss] GCC Targets
  • Date: Sat, 5 Oct 2002 16:07:37 +0100

Hello Ryan,

Saturday, October 5, 2002, 2:59:35 PM, you wrote:

RA> If you start making the hardware detection part of different spells you
RA> will encounter two problems:

RA> 1) It will get fragmented and duplicated across multiple spells.

Only where appropriate. As I thought I'd explained, the cpudetect
stuff is actually just generating the appropriate gcc flags. So if
someone wanted to use say IBMs compiler, then this routine is no use
to them. The IBM compiler spell would have it's own version of the
cpudetect routines to produce IBM compiler flags. As mine is gcc
specific then it seems logical to stick it in the gcc spell. Why do
you see this as wrong?

RA> 2) It will not work in sorcery 2.0 at all.

It's a bit premature to say that don't you think?

RA> Sorcery 2.0 will be defining a more rigid structure for spells, and
RA> generally separating them from sorcery more, via a cleaner api.

I thought my libvariables idea was a cleaner API that seperated
spells, or at least their variables, from sorcery more. Do you
disagree and if so can you explain why?

>> So to recap, next cpudetect will contain:
>>
>> libvariables : lookup and save routines
>> cpu2gcc : code to scan cpuinfo and produce TARGET file
>> cpu2gcc refs : lookup tables for auto target generation
>> autocpu : reads local TARGET and sets sorcery bash vars

The only bit of this that is tied to Sorcery is autocpu. In fact by
replacing autocpu with different code, this system could integrate
with ANY source based distro. I designed it this way so that it could
promoted seperately to:

1) Get more cpuinfos than are in use with sourcemage
2) Promote sourcemage to that wider audience - "Now you know what gcc
flags to use, did you know that sourcemage can download, compile and
install code optimised to your system with one single command?"

But if you want to summarily dismiss the work as not sourcemage 2.0
compatible I'm sure I can find a suitable alternative distro to work
with. Your loss not mine. cpudetect might be my first bash program,
but I do have 20 years of programming experience across a lot of other
languages.

Be interesting to see how the community reacts to this discussion. Is
SourceMage development driven by user needs or by someone at the top's
idea of where it should go? Hate to say it, but didn't we have this
problem before?

--
Best regards,
Mark mailto:msasgl AT msa-enterprises.com





Archive powered by MHonArc 2.6.24.

Top of Page