All of lore.kernel.org
 help / color / mirror / Atom feed
From: mjn3@codepoet.org (Manuel Novoa III)
To: Riley Williams <Riley@Williams.Name>
Cc: ELKS <Linux-8086@Vger.Kernel.Org>
Subject: Re: New version of Bob's C compiler
Date: Thu, 25 Jul 2002 14:36:11 -0600	[thread overview]
Message-ID: <20020725203611.GA7007@codepoet.org> (raw)
In-Reply-To: <Pine.LNX.4.21.0207252036400.30515-100000@Consulate.UFP.CX>

Hi Riley,

On Thu, Jul 25, 2002 at 08:56:25PM +0100, Riley Williams wrote:
> My original reply actually mis-read the question - I was referring to
> converting ELKS to require the latest BCC compiler, and my instincts say
> that we're being far too hasty at this point, and need to wait until the
> new BCC version is in general circulation before we do so. However, if
> the general concensus is that we should do so, I will fall in line.

Ah.  I too misunderstood.  I thought you were talking about mentioning
in the ELKS docs where to find the latest bcc.  I remember you had asked
me that very question several weeks ago.

> >> Who wants to conduct a poll to decide whether this is a good or bad
> >> idea? I can see viewpoints both ways...
> >> 
> >> FOR:     Much of ELKS becomes simpler with the latest facilities.
> 
> > I for one need the new features.  ;-)
> 
> I could make good use of them as well...but that is pretty much
> irrelevant to this discussion as we can already make use of the new
> facilities in our own projects whether we use them in ELKS or not.

True.  As I said above, I misunderstood.

> >> AGAINST: ELKS becomes dependent on having the latest BCC compiler.
> 
> > Is this really much of a drawback? Building bcc isn't that big
> > an issue.
> 
> Are you willing to be the one to deal with all the "ELKS doesn't
> compile" spam that will result from the people who download ELKS onto
> their system, then try to compile it and it throws up lots of error
> messages simply because they have an old version of BCC installed and
> we rely on a new version with lots of enhancements not in the commonly
> installed versions?

Not even _remotely_ likely.  ;-)  I see too much of that nonsense
already on the busybox and uClibc mailing lists.  I've got no
patience for it.

> I'm not - I had enough of that from HarKal when ELKS was sensitive to
> a difference between his system configuration and mine with the result
> that it compiled here but not on his system. We sorted that out a while
> back and removed the said sensitivity from ELKS, but this will bring in
> far more sensitivities than I'm willing to deal with.
> 
> As far as I can tell, RedHat issues a new release about every six weeks
> from what I've seen, and the other major distributors appear to issue
> releases at about the same rate. Also, apart from the major Linux
> developers (like myself), most Linux users I know keep their systems
> updated to within three releases of the current one.
> 
> My proposal would therefore be to work towards getting the BCC with
> these major enhancements included in all the major distributions, then
> give that four months to percolate through the userbase. At that point,
> 90%+ of the Linux userbase will have the relevant compiler, and we can
> start making changes that depend on those facilities without worrying
> about problems like this.

No matter what, there will need to be some test in the ELKS build that
waives a red flag for those trying to use an old version of bcc.  We
still see posts from people on the uClibc mailing list about bugs in
the older uC-libc that is being packaged with uClinux by some groups.
Just the other day, someone posted a message about printf behavior
that I fixed in uClibc over 18 months ago.  :-(

Manuel

  reply	other threads:[~2002-07-25 20:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-24 22:08 New version of Bob's C compiler Gregg C Levine
2002-07-24 22:15 ` Riley Williams
2002-07-24 22:34   ` Paul Nasrat
2002-07-25  5:59     ` Riley Williams
2002-07-25  7:15       ` Paul Nasrat
2002-07-25  8:09       ` Harry Kalogirou
2002-07-25 19:28         ` Blaz Antonic
2002-07-25 16:38   ` Manuel Novoa III
2002-07-25 19:56     ` Riley Williams
2002-07-25 20:36       ` Manuel Novoa III [this message]
2002-07-26 18:27       ` Harry Kalogirou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020725203611.GA7007@codepoet.org \
    --to=mjn3@codepoet.org \
    --cc=Linux-8086@Vger.Kernel.Org \
    --cc=Riley@Williams.Name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.