New version of Bob's C compiler

New version of Bob's C compiler

[Gregg C Levine]

Hello from Gregg C Levine
Go ahead folks and send me flaming mail off list, but here goes. If a new
one has been posted to his page, then will it be mirrored anywhere on the
general ELKS pages, and FTP sites?
Gregg C Levine obiwanthejediknight@att.net
<This signature will be replaced, pending an approval from the Jedi Council.
>

Re: New version of Bob's C compiler

[Riley Williams]

Hi Gregg.

> Go ahead folks and send me flaming mail off list, but here goes.
> If a new one has been posted to his page, then will it be mirrored
> anywhere on the general ELKS pages, and FTP sites?

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.

AGIN:	ELKS becomes dependent on having the latest BCC compiler.

...and I'm not willing to make this decision myself.

Best wishes from Riley.

Re: New version of Bob's C compiler

[Paul Nasrat]

On Wed, Jul 24, 2002 at 11:15:48PM +0100, Riley Williams wrote:
> Hi Gregg.
> 
> > Go ahead folks and send me flaming mail off list, but here goes.
> > If a new one has been posted to his page, then will it be mirrored
> > anywhere on the general ELKS pages, and FTP sites?
> 
> 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.
> 
> AGIN:	ELKS becomes dependent on having the latest BCC compiler.

True, elks should be still compilable on the common distro Dev86
package.  However, I will go and package up both a Mandrake style and
RedHat stye rpm and be happy to submit those to all, if we can encourage
package maintainers to update then it's not too nasty to ask ppl who
compile from source to ensure they are using a recent edition.

By the looks of it Debian unstable is on 0.16.3 anyway so are probably
keeping an eye out on Robert's page.

Maybe we should say the next major release of Elks will require a recent
Dev86, and concentrate on helping distro's get the most recent Dev86 and
dosemu and elksemu happily working.  Then we can try and clean up the
code based on new compiler features.

BTW, I think things are broken for SIBO atm, need to fix but need
time...

Paul

Re: New version of Bob's C compiler

[Riley Williams]

Hi Paul.

>>> Go ahead folks and send me flaming mail off list, but here goes.
>>> If a new one has been posted to his page, then will it be mirrored
>>> anywhere on the general ELKS pages, and FTP sites?

>> 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.
>>
>> AGAINST:	ELKS becomes dependent on having the latest BCC compiler.

> True, elks should be still compilable on the common distro Dev86
> package. However, I will go and package up both a Mandrake style and
> RedHat stye rpm and be happy to submit those to all, if we can
> encourage package maintainers to update then it's not too nasty to
> ask ppl who compile from source to ensure they are using a recent
> edition.

I'm willing to insert the relevant check in the ELKS Makefile PROVIDING
there's a way of determining the version of dev86 that is installed that
is both easy and reliable...

> By the looks of it Debian unstable is on 0.16.3 anyway so are
> probably keeping an eye out on Robert's page.

I'm on a system based on RedHat 6.2 here, and I've yet to see later than
dev86-0.15.0-2 for it.

> Maybe we should say the next major release of Elks will require a
> recent Dev86, and concentrate on helping distro's get the most
> recent Dev86 and dosemu and elksemu happily working. Then we can try
> and clean up the code based on new compiler features.

We're almost ready to release ELKS 0.1.1 as I see it. Once that's out,
I'm willing to aim for 0.2.0 requiring a recent dev86

> BTW, I think things are broken for SIBO atm, need to fix but need
> time...

Personally, I'd like to see SiBO listed as a separate architecture where
it matters, rather than the current situation where tweaks for either
the XT or SiBO pretty much automatically break the other...

Also, I'd like to rearrange the codebase such that all source files
that contain assembler are under arch/* and source files without any
assembler in them are NOT under arch/* but I'd want agreement with
that idea before I started on it.

Best wishes from Riley.

Re: New version of Bob's C compiler

[Paul Nasrat]

On Thu, Jul 25, 2002 at 06:59:45AM +0100, Riley Williams wrote:
 
> > By the looks of it Debian unstable is on 0.16.3 anyway so are
> > probably keeping an eye out on Robert's page.
> 
> I'm on a system based on RedHat 6.2 here, and I've yet to see later than
> dev86-0.15.0-2 for it.

limbo (RH 8 beta) and rawhide have 0.16.3, Mandrake is on 0.15.5 in
cooker according to rpmfind, but I can't see it on mirror.ac.uk's cooker
archive.

I'll update the src.rpm from 0.15.5 to 0.16.5, upload it and post an RFE
for Mandrake 9.0 beta to ship it.

Paul 

Re: New version of Bob's C compiler

[Harry Kalogirou]

Την Πεμ, 25-07-2002 στις 08:59, ο/η Riley Williams έγραψε:
> Also, I'd like to rearrange the codebase such that all source files
> that contain assembler are under arch/* and source files without any
> assembler in them are NOT under arch/* but I'd want agreement with
> that idea before I started on it.

I thing this should start after 0.2.0 because it will destabilise the
system a lot. I also have to note that a source file can be platoform
depentent even without containing assembler. 

Harry


-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New version of Bob's C compiler

[Blaz Antonic]

As pointed out by Harry i managed to miss the CC field :) Here it goes
again:

> > Also, I'd like to rearrange the codebase such that all source files
> > that contain assembler are under arch/* and source files without any
> > assembler in them are NOT under arch/* but I'd want agreement with
> > that idea before I started on it.
> 
> I thing this should start after 0.2.0 because it will destabilise the
> system a lot. I also have to note that a source file can be platoform
> depentent even without containing assembler.

... as in /arch/i86/drivers/* at the moment. I don't think splitting
those up would be a good idea. Linux has drivers in /drivers directory
(not under arch) despite the fact that most of them are arch-specific
but nevertheless it think ELKS' approach is better (more logical if you
will).

Blaz Antonic

Re: New version of Bob's C compiler

[Manuel Novoa III]

Riley,

On Wed, Jul 24, 2002 at 11:15:48PM +0100, Riley Williams wrote:
> Hi Gregg.
> 
> > Go ahead folks and send me flaming mail off list, but here goes.
> > If a new one has been posted to his page, then will it be mirrored
> > anywhere on the general ELKS pages, and FTP sites?
> 
> 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.  ;-)

> AGIN:	ELKS becomes dependent on having the latest BCC compiler.

Is this really much of a drawback?  Building bcc isn't that big
an issue.

Manuel

Re: New version of Bob's C compiler

[Riley Williams]

Hi Manuel.

>>> Go ahead folks and send me flaming mail off list, but here goes.
>>> If a new one has been posted to his page, then will it be mirrored
>>> anywhere on the general ELKS pages, and FTP sites?

As far as mirroring the BCC releases on the ELKS pages, remember they're
on Sourceforge, and I think the SF terms and conditions prohibit using
sourceforge as a mirror.

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.

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

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

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.

Best wishes from Riley.

Re: New version of Bob's C compiler

[Manuel Novoa III]

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

Re: New version of Bob's C compiler

[Harry Kalogirou]

Την Πεμ, 25-07-2002 στις 22:56, ο/η Riley Williams έγραψε:

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

A simple BCC version check at the begining of compilation, will solve
all the problems. And for sure the BCC version check is going be much
smaller that this thread in lines.
 
> 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.

Requiring a specific version of some kind of tool is one thing and
requiring specific system configuration is an other. I beleave that we
can safely use the latest compiler; The one that will like to compile
from source, will find a way to get tha compiler.

Harry



-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html