Re: cc65 and "Hello World"
- From: magnusfalkirk <dean.phares@xxxxxxxxx>
- Date: Thu, 17 Apr 2008 10:55:43 -0700 (PDT)
On Apr 17, 7:22 am, Bill Buckels <bbuck...@xxxxxxxxx> wrote:
On Apr 17, 12:43 am, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:
I've never seen a software development that didn't rely on some
such process. The alternative is to hold back releasing new bits
until they are thoroughly tested, but then the testers don't get
them--a contradiction in terms.
If you say so. So what's your hurry? Here's some more tunnel vision
again...
I could perhaps see a complicated build process for a large project
like a portfolio management application which hosts quote services and
an order entry system. Or if a large team is required.
For a compiler project I cannot see this. Perhaps I have missed an
important understanding of what is going-on here. There is a working
compiler, assembler, linker, and library manager. Perhaps there is a
debugger and perhaps the linker allows the embedding of debug symbols,
and perhaps one can attach, detach, trace and step through in the
debugger. Perhaps not. If not this is of a relatively simple scope.
Change management starts at the top. The rationale for a change is
documented and reviewed. A risk benefit analysis is performed and if
the change is approved it is scheduled for a particular release.
That's of course part of the quality plan.
Regardless, there is no real need to provide QA with a product for
system testing and "black box" testing until the programming on a
particular unit is done, until the tracing and test harness have been
performed and until the code walkthrough has been done. In fact the
changes should not be checked-in until that is accomplished.
CVS is not ideal for this level of change control and RCS is probably
better in some ways using strict locks.
Therefore development builds from scratch and gets the latest checked-
in code which is stable and makes changes to a stable codebase.
Development does unit testing based on a test frame and test scripts.
If regression testing is required it is done at that level first. The
boundary and equivalence tests are determined in the test script and
the test frame reflects the individual sets that need to be performed.
After development have released the tested and finished latest changes
to QA by way of a release, the high level and system testing and
finally acceptance testing on behalf of the user is done. It is then
and only then after this process is completed that a release candidate
should be available for alpha or beta.
The development and testing of libraries and library routines is
completely independent of the development and testing of a binary
executable in a project like a compiler. In fact link libraries and
headers can be considered "baggage" independently from the compiler
itself and its core binaries.
Tools and utilities too can and should be considered separately.
So major achitectural changes to a compiler should not be mixed with
minor changes to link libraries.
A product lifecycle is part and parcel of all of this. So is
documentation.
Now anyone who wants to compare a properly managed change control
system and properly isolated developement, QA, and production areas
which is what I prefer, with some sales guy who walks over to a
development machine and raids it...
Well I promised Oliver I would be nice, so I'll just say this and be
on my merry way...
If anyone here doesn't think I fully tested every aspect of each of
the compilers that I made available from the Aztec C Website before
releasing them for download then they have not used what I put online.
Hey this stuff was really hard to find and put together and to write
the scripts and write and compile the pieces that weren't there and so
forth. I couldn't sluff it.
So I am not standing in a glass house throwing stones. I am not even
throwing stones except really soft ones and really just asking why are
you doing it this way???
Also if anyone thinks this Aztec C stuff that I talk about is native
mode and not cross-compiler well then they haven't looked. Suggesting
that I read your labels when you haven't looked at my work is somewhat
interesting to say the least...
The Aztec C for the Apple II, Commodore 64, and CP/M 80 (8080 and Z80)
and CP/M 86 are all available in cross-compilers and in native mode
compilers. Download them and look.
The level of ANSI compliance is relative to the compilers of course,
but since Aztec C was until Microsoft pushed them out of existence a
leader in embedded systems and cross compilation, as well as providing
floating point support, this should not be discounted as a poorly
written or less capable development environment for 6502 based
machines nor for Z80 or 8080.
In fact this is the one to match if you are serious about meeting some
standards of excellence.
That assembly pass is really good with these. A person could reverse
engineer that back to an ANSI compiler without too much thought but it
will be easier with the source.
As far as other compilers and Z80 stuff and so forth you should see
the constant volume of my email on all of this over the years. Yes
there are lots of great compilers out there. My new favorite is
Digital Mars by Walter Bright. (The D Programming Language is
interesting too) And speaking of great distributions...
My distributions are also a good example to follow, because one click
and good examples are always appreciated by end users who may not be
interested in how you are making the compiler. They are more
interested in how they can use it to make their own programs.
As far as reading some label or another, oh well, that is your thing
not mine. Why would an experienced developer even look at something
that doesn't work? To fix it? Got lots of my own stuff to fix... not
looking for more broken stuff. By the same token someone else migh say
why look at old stuff when I got new stuff...
Regards,
Bill Buckels
PS - when I get the source for all this and talk to some of the guys
who moved Aztec C to ANSII I'll be doing the Apple II stuff first
because I understand because I have been told by those who were there
that it was almost already finished ANSII-able ready.
Bill,
It sounds to me like what you are describing is software developed by
a team that is together in one place and working for a company. What
people here have been trying to describe to you, and you're somehow
missing the point, is that things like cc65 are developed by a group
of people located in different places around the world. Go take a look
around http://www.sourceforge.net and you'll see all kinds of similar
projects, with people volunteering time from around the world to work
together on some common software project. So there is a need for a
"nightly build" so that the different people working on it can see
what the latest progress is.
Just my two cents,
Dean
.
- References:
- cc65 and "Hello World"
- From: Gio
- Re: cc65 and "Hello World"
- From: U. v. Bassewitz
- Re: cc65 and "Hello World"
- From: Gio
- Re: cc65 and "Hello World"
- From: U. v. Bassewitz
- Re: cc65 and "Hello World"
- From: Bill Buckels
- Re: cc65 and "Hello World"
- From: U. v. Bassewitz
- Re: cc65 and "Hello World"
- From: Bill Buckels
- Re: cc65 and "Hello World"
- From: Michael J. Mahon
- Re: cc65 and "Hello World"
- From: Bill Buckels
- Re: cc65 and "Hello World"
- From: Michael J. Mahon
- Re: cc65 and "Hello World"
- From: Bill Buckels
- cc65 and "Hello World"
- Prev by Date: Re: cc65 and "Hello World"
- Next by Date: Re: cc65 and "Hello World"
- Previous by thread: Re: cc65 and "Hello World"
- Next by thread: Re: cc65 and "Hello World"
- Index(es):
Relevant Pages
|
Loading
