View Single Post
Old 19 October 2016, 10:57   #177
Olaf Barthel
Registered User
Join Date: Aug 2010
Location: Lehrte, Germany
Posts: 86
Originally Posted by Locutus View Post
I think that's sticking to a vision of 1989 a bit, i don't mean it offensively but hold on a for a minute :-)

That is looking at the perspective of working on AmigaOS as a true general purpose OS which should be fit for all use and on which you expect to also run and improve your (or the third party) development tools while you are at it.

Those conditions don't hold true any more. Nowadays AmigaOS has only very specific application areas and you don't expect it to have the best native development any more.

As such I would see working on it far more like how you would work on a VxWorks or Embedded Linux based system.
I cannot quite picture this. For now AmigaOS 3.1 appears to be useful only in the context of virtualization, emulation and legacy hardware (modified or unmodified). As such the best possible outcome for it which I could imagine today would be a platform for tinkerers, hobbyists and "makers".

Of course this doesn't mean your system shouldn't have proper unit tests etc :-)
That would be an interesting subject all by itself!

Does anybody reading this thread have experience in how to deal with legacy code on a platform which was developed using assembly language and 'C'?

The most straightforward definition of "legacy" code I read in recent years was that it referred to program code which lacked testing mechanisms.

The literature which I found on the subject was not particularly helpful, because it covered testing only in the context of object oriented programming languages.

Rewriting the existing code in a language which makes this kind of testing easier seems to be a non-starter. I already received some criticism for even suggesting that assembly language has its limitations.

How do you retrofit tests to this type of code? Is this even a good idea?

From what I have seen from the terrible AmigaOS 'build system' and read from you're comments I would take a bit more 'brutalist' approach to getting this to work.
You make it sound worse than it actually is. The current solution did not even exist in 1993. When Commodore gradually switched to native development, the original build system ("makemeta", which was built around the SunOS "make" utility) was phased out.

Each Commodore engineer was basically his own build engineer, and no two operating system components were likely to have anything in common when it came to building them.

The current build system uses GNU make and, with the exception of the process which cranks out ROM images and disks, is self-configuring with regard to what needs to be built. It's documented, the complete source code to all the tools is available. It's only 18 years old, and judging from today's offerings in terms of build systems, I find it hard to discard "make".

Those who do not know "make" are bound to reinvent it over and over again, poorly

But then again, those who know "make" often wish they had something better instead...
Olaf Barthel is offline  
Page generated in 0.05083 seconds with 9 queries