ToolKit
Universal SDK for Amiga projects
|
A web, suddenly
Forty years meditation
Minds awaken, free
|
Overview
ToolKit is a standard SDK configuration and universal developer experience for Amiga developers and power users. The main ToolKit repository is Work in progress, matching the project catalogue on the amigazen home page.
The ToolKit project aims to standardise the development tool and SDK configurations for classic Amiga developers, in order to make collaboration easier in the 21st century world of online collaboration and open source.
It is intended that a fully automated installation of ToolKit, currently in development, will soon be available here in this project repository.
ToolKit is a universal standard for development environments on Amiga, designed to make collaboration easier by ensuring everyone has their developer tools in the same places with their SDK configured identically. This standardization means that a project that builds and runs on one machine will build and run identically on another, eliminating the "works on my machine" problem that has plagued Amiga development for decades.
Most Amiga software was written in the 1980s and 90s by individuals working alone, each with their own preferred setup for where their dev tools are run from, where their include files, static libs and other toolchain artifacts could be found, which versions they used and which custom modifications they made. Open source collaboration as we know it today simply didn't exist back then. ToolKit changes that by providing a universal standard that makes collaboration easier.
|
What Problems Does ToolKit Solve?
Inconsistent Development Environments: Each Amiga developer has historically had their own preferred setup for where dev tools are run from, where include files and static libs are located, which versions they use, and which custom modifications they make.
Collaboration Barriers: Open source collaboration as we know it today simply didn't exist when most Amiga software was written, making it nearly impossible for developers to work together effectively.
Build Reliability Issues: Projects that build on one machine often fail to build on another due to different toolchain configurations, include paths, and library locations.
Setup Complexity: New developers face significant barriers to entry when trying to set up development environments that match existing project requirements.
|
|
Third-Party Dependencies
The following components are required but not included in the ToolKit distribution:
|
Setup your ToolKit
The ToolKit project aims to standardise the development tool and SDK configurations for classic Amiga developers, in order to make collaboration easier in the 21st century world of online collaboration and open source.
It is intended that a fully automated installation of ToolKit, currently in development, will soon be available here in this project repository.
Until that time, you can setup a ToolKit compatible SDK by following these instructions:
- Unpack the ToolKit SDK.lha archive to a suitable location with enough storage and working space e.g. Work:SDK
- Assign SDK: to this location and ensure this is set in your User-Startup or SDK-Startup (provided with ToolKit) shell script
- Download and unpack the latest Amiga NDK to a similarly suitable location, usually the directory 'NDK' inside your SDK location
-- At the time of writing the NDK is available at (https://www.hyperion-entertainment.com/index.php/downloads?view=download&layout=form&file=126)
- Assign NDK to this location and ensure this is also set in your User-Startup or SDK-Startup (provided with ToolKit) shell script
- Ensure you have at least one of the supported C compilers installed (see below) and more importantly that you have the C compiler compatible to the project you wish to build - not all ToolKit compatible projects support all compilers
- For VBCC, unpack the ToolKit_VBCC.lha on top of your VBCC installation, this will install PosixLib configuration
Follow these remaining steps:
;BEGIN ToolKit
Assign >NIL: SDK: {SDK_PATH}
Assign >NIL: include: SDK:Include_H ADD
Assign >NIL: include: SDK:Include_I ADD
Assign >NIL: lib: SDK:lib
Assign >NIL: Libs: SDK:Libs ADD
Assign >NIL: NDK: {NDK_PATH}
Assign >NIL: lib: NDK:lib ADD
Assign include: NDK:Include_H ADD
Assign include: NDK:Include_I ADD
Assign netinclude: NDK:SANA+RoadshowTCP-IP/netinclude
Path SDK:C NDK:C ADD
;END ToolKit
Then finally:
From the NDK folder:
- Copy NDK:Tools/CatComp/CatComp to SDK:C/
- Download the following additional SDK components as required by your projects
- For AmiSSL, download the latest release of (https://www.aminet.net/util/libs/AmiSSL-v5-SDK.lha)
-- Unpack the AmiSSL-v5-SDK archive to a location of your choice such as _SDK:Local_
-- Assign sslinclude: to the AmiSSL include directory e.g. `Assign sslinclude: SDK:Local/AmiSSL/include ADD`
- For P96, download the latest release of (https://wiki.icomp.de/w/images/e/e9/Develop.lha)
-- Unpack the Develop archive to a location of your choice such as _SDK:Local_
-- Move or copy the following files to your SDK: location
-- lib/picasso96.lib -> SDK:lib/picasso96.lib
-- libraries/picasso96.h -> SDK:Include_h/libraries/picasso96.h
-- TODO: Copy the rest of the P96 include files
Note that the NDK and other complex SDKs such as the AmiSSL SDK are kept separate from the ToolKit directories, so that they can be updated independently without having to figure out which files have changed and merge directories.
|
Compiler Support
ToolKit compliant projects must support at least one of the supported compilers, however not all projects will support all compilers. Indeed it's likely that a project will only support one specific compiler unless work has been done to add additional configurations.
As a rule of thumb, choose a C compiler that best suits your project:
• For updating most legacy projects, use SAS/C
• For the small number of legacy open source projects that used DICE, use the DICE-nx compiler instead
• For brand new projects and for targeting all Amiga-like platforms, use VBCC
• For porting projects that use standard C and are inherently meant to be POSIX portable use VBCC together with the PosixLib configuration
• For linux porting projects or projects that need a combined classic Amiga and OS4 code base, use GCC and the rest of the ADE tools
SAS/C
The SAS/C compiler, version 6.58 or the later 7.0 release with experimental C++ support, was and still is the most popular C compiler used for classic Amiga projects - many open source releases on Aminet and elsewhere expect the developer to have SAS/C.
SAS/C for Amiga has not been sold commercially since the early 1990s but many developers will likely have access to a copy.
ToolKit is designed to work with an out of the box install of SAS/C in the normal locations, that is, make sure that your SAS/C installation has been setup like this wherever you have installed it (e.g. in _SDK:sc/_):
;BEGIN SAS/C
Assign >NIL: sc: SDK:sc
Assign >NIL: lib: sc:lib ADD
Assign >NIL: include: sc:include ADD
Assign >NIL: cxxinclude: sc:cxxinclude
Path >NIL: sc:c ADD
;END SAS/C
Do NOT put any static libraries or include files apart from the ones that come with SAS/C into the sc: directories, this will defeat the object of using ToolKit's standardised configuration. Using ToolKit you can keep your SAS/C installation clean.
To differentiate SAS/C makefiles from other makefiles, ToolKit projects will always name them _smakefile_
VBCC
The VBCC compiler is a great alternative to SAS/C with better support for C standards, and a universal configuration for both native and cross compilation, as well as support for all Amiga-like platforms.
ToolKit also includes the GNU **make** command which is the preferred build driver to use with VBCC.
ToolKit does not include the VBCC directly - you will need to download it from http://sun.hasenbraten.de/vbcc/
Get both the compiler archive http://phoenix.owl.de/vbcc/current/vbcc_bin_amigaos68k.lha and the target archive http://phoenix.owl.de/vbcc/current/vbcc_target_m68k-amigaos.lha
Unpack them both and run the installer, making sure that your User-Startup or SDK-Startup is correctly set up to point to your installation location e.g. _SDK:vbcc_
;BEGIN vbcc
Assign >NIL: vbcc: SDK:vbcc
Path >NIL: vbcc:bin ADD
SetEnv VBCC vbcc:
;BEGIN vbcc-m68k-amigaos
Assign >NIL: vincludeos3: vbcc:targets/m68k-amigaos/include
Assign >NIL: vincludeos3: "include:" ADD
Assign >NIL: vlibos3: vbcc:targets/m68k-amigaos/lib
;END vbcc-m68k-amigaos
;END vbcc
Then get the VBCC PosixLib from https://www.aminet.net/dev/c/vbcc_PosixLib.lha and unpack this to the same location where you installed the VBCC target
ToolKit includes a ready-made configuration to use VBCC with the VBCC PosixLib. Unpack the ToolKit_VBCC.lha archive over the top of your VBCC install.
Do NOT put any static libraries or include files apart from the ones that come with VBCC into the vbcc: directories, this will defeat the object of using ToolKit's standardised configuration. Using ToolKit you can keep your VBCC installation almost clean, except for the PosixLib configurations.
To differentiate VBCC makefiles from other makefiles such as those meant for use with GCC, ToolKit has adopted the name 'vmakefile' for any makefile designed to be used with VBCC, although vmakefiles are in fact still valid GNU make files. Since make will not automatically find a vmakefile in the current directory, you can usually build the project with:
make -f vmakefile
GCC
For now, it is enough to install the _Amiga Development Environment_ or _ADE_ (a project similar to and one of the inspirations for _ToolKit_), following these instructions:
1) Unpack the archive https://www.aminet.net/dev/gcc/ADE.lha to a suitable location e.g. SDK:ADE/
2) Unpack the archive https://www.aminet.net/dev/gcc/ADE-repack.lha over the top of the same location (the repack release is missing some crucial empty directories needed by ADE-startup)
3) Set the ADE-Startup script to run in your User-Startup or add it to your ToolKit SDK-Startup. N.B. do not run it more than once per session.
4) TODO: Instructions on configuring ADE to use the NDK3.2 os-include folder instead of the ones it comes with
5) TODO: Instructions for setting up ADE to use latest libnix and clib2 builds
Where a project uses GCC, the makefile will be called simply _makefile_ and the driver will be the same SDK:C/make used with VBCC
DICE
ToolKit does not currently support the DICE C compiler however since DICE has been made open source, you can find a working version here https://github.com/dice-nx - it is expected that DICE support will eventually be added to ToolKit.
StormC, Aztec C, Lattice C, HiSoft C++, Maxon C++
These older, proprietary compilers are not supported by ToolKit even though they are supported by the latest NDK. Still, contributions are welcome if anyone wishes to see ToolKit support these compilers.
|
Standard Directory Structure
The ToolKit standard defines a consistent directory structure that all developers follow:
SDK: # Root SDK directory (assigned to SDK: in S:sdk-startup)
+-- Include_h/ # C include files for ToolKit libraries
+-- Include_i/ # Assembler include files for ToolKit libraries
+-- emodules/ # Amiga E modules for ToolKit libraries
+-- NDK/ # Unpack NDK3.2 here and assign to NDK: in S: sdk-startup. ToolKit will set up standard assigns and paths to include the NDK drawers in the global configuration
+-- sslinclude/ # AmiSSL security includes (assigned to sslinclude: in S:sdk-startup)
+-- C/ # ToolKit's toolchain - command line tools such as make, ctags and rman. (added to PATH in S:sdk-startup)
+-- lib/ # Static link library binaries for ToolKit static libraries (assign ADD'ed to LIB: in S:sdk-startup)
+-- libs/ # Binary tools for ToolKit (assign ADD'ed to LIBS: in S:sdk-startup)
+-- doc/ # Autodocs for ToolKit libraries
+-- docs/ # Documentation for ToolKit command line tools
|
|
GitHub Repositories
The All Projects catalogue lists the ToolKit SDK group, the MediaTypes group, and the PowerTools group separately. Below matches that split. Other flagship and standalone repos (AWeb, AmigaPython, unsui, Engi, and so on) are only on the home page table.
All source is on GitHub under open source licences. Fork a repo, open issues, or send pull requests there.
|
ToolKit
|
ToolKit
Universal Amiga SDK
APP
C++ Amiga API wrapper
ASAP
C++ Amiga API wrapper
asyncio.library
Async I/O library
BGUI
BOOPSI GUI framework
btree.library
btree function library
clib2-amiga
Standard C library (gcc & SAS/C)
Codex
Amiga C style checker
crc.library
CRC and message-digest shared library
ctags-amiga
ctags
DiffView
A diff viewer
etags-amiga
GNU etags
expat.library
expat XML parser shared library
GadToolsBox
Interface builder
ga.lib
Graphics Architecture static lib
Gen
GenDo, GenIn & GenMaki build tools
gtdrag.library
GadTools drag-and-drop
|
gtlayout.library
GadTools layout
InAction
BOOPSI classes
Insight
Debugger
Introspection
Introspection tool
libnix-amiga
Standard C library for gcc
LhASsA
Lh Archive Sub-System (LhA)
LogBook
The system log
LZXa
Open source LZX archiver
make-amiga
GNU make 4.4.1
mushin
muimaster.library reimplementation
Objection
Objective-C for Amiga
OberonA
Oberon compiler
OpenTriton
Triton GUI framework
OUI
C++ Amiga API wrapper
popupmenu.library
Popup menus
|
pcre.library
PCRE shared library
reaction.lib
ReAction static autoopen lib
regexp.library
Regex parser
rman-amiga
rman / PolyglotMan
rtasl.lib
Use ASL instead of reqtools
Scion
SAS/C extensions
Seiso
Cleanup stack
tb.lib
AISS image helper
texinfo-amiga
Texinfo
ToolChain
C compiler, assembler and linker
ttengine.library
TrueType / OpenType engine
z.library
ZLib as a shared library for Amiga
|
MediaTypes
DataTypes, MIME media types, IFF tools, PostScript, HotLinks, and related viewers — companion to FastForward
|
DataType
Filetype identification tool
DocsDT
document.datatype (IFF DOCS)
DrawingDT
drawing.datatype, DR2D, SVG, Illustrator
egami.lib
Native PDF reader/writer
HotLinks
Pub/Sub linking library
|
IFFTools
IFF tools (was iff2png)
iffparse
IFF parser (in IFFTools)
MarkdownDT
Markdown DataType
MediaTypes
MIME media types library
MovieDT
movie.datatype (uses FastForward)
|
MusicDT
music / instrument DataTypes
Post
post.library PostScript
Show
MediaTypes file viewer
SVGPictureDT
SVG bitmap Picture DataType
|
|
PowerTools
|
Clipboard
Clipboard CLI tool
CShell
Unix-like shell
FileTypes
Syntax highlighting for TextEdit / CodeCraft
|
Open
Universal Open command
ProjectX
Universal DefaultTool
TTX
Text editor
|
ToolManager
Workbench dock
WBTrash
Universal Workbench Trashcan
Workspace
Public screen manager
|
|
1990s Application Frameworks: The Foundation of Modern Development
The 1990s were a pivotal decade in software development, marking the transition from procedural programming to object-oriented architectures. During this period, several innovative frameworks emerged that would shape the future of application development across all platforms.
Amiga Frameworks: Pioneering Object-Oriented GUI Development
The Amiga platform was particularly innovative during this era, with several frameworks that introduced concepts that would later become standard in modern development:
• AppShell - Message-driven application framework with multi-project support, ARexx integration, and AppObjects GUI system
• Triton - BOOPSI-based object system for GUI development, providing 18 GUI classes with custom memory management
• APlusPlus - C++-based application framework with object-oriented GUI development and AmigaOS signal integration
• MUI (Magic User Interface) - Advanced object-oriented GUI framework with automatic layout management and extensive customization
• BGUI Analysis - Comprehensive analysis of the BOOPSI-based GUI framework with 32 GUI classes and custom memory management
• Frameworks Comparison - Comparative analysis of Triton, BGUI, APlusPlus, and AppShell
• BGUI API Documentation - Complete reference documentation for all BGUI classes, methods, and programming examples
|
• ReAction - Modernized GadTools-based framework providing enhanced versions of standard Amiga controls
• ClassAct / Reaction - BOOPSI class library for creating custom GUI components and dialogs
• GadTools - Amiga's native GUI toolkit providing the foundation for higher-level frameworks
|
Influence on Modern Frameworks
Many concepts pioneered by these Amiga frameworks found their way into modern development environments:
• Qt Framework - Signal-slot mechanism and cross-platform widget system
• MDI (Multiple Document Interface) - Multi-window document management pioneered by Windows frameworks
• AppKit (macOS) - Object-oriented application framework with automatic memory management
|
• Cocoa (macOS) - Model-View-Controller architecture and automatic layout management
• WPF (.NET) - Declarative UI design and data binding concepts
• Android Framework - Component-based architecture and resource management
|
These frameworks demonstrated that object-oriented approaches could significantly improve developer productivity and code maintainability, even on resource-constrained systems. Today, with modern hardware providing abundant memory and processing power, the concepts they pioneered have become standard practice in software development.
|
C Libraries for Amiga: Understanding Your Compiler's Standard Library
One of the most important aspects of Amiga development is understanding which C standard library functions are available with your chosen compiler. Different Amiga C compilers come with different standard libraries, each offering varying levels of POSIX compliance and proprietary extensions.
Compiler and Library Compatibility
SAS/C 6.58 - Links against sc.lib (SAS/C's C library) and includes many Amiga-specific extensions. POSIX support is partial; refer to the tables for exact availability.
VBCC - Links against vc.lib by default and can use PosixLib for additional POSIX APIs. It does not use libnix. POSIX coverage depends on PosixLib; see its documentation and the function tables for details.
GCC - On classic Amiga, GCC links against libnix or clib2 (not glibc). Both provide partial POSIX support with different trade-offs; consult the function tables (e.g., libnix POSIX, clib2 reference) for specifics.
Why This Matters for Development
Understanding your compiler's standard library capabilities is crucial for:
• Portability - Knowing which functions are available helps you write code that works across different compilers
• Feature Selection - Choosing the right compiler based on your project's standard library requirements
• Debugging - Understanding why certain code might compile with one compiler but not another
• Optimization - Using compiler-specific extensions when available for better performance
Comprehensive Library Reference
We've created a comprehensive reference section that documents which standard library and POSIX functions are available in each C library:
Complete Reference Documentation
For a complete overview of all available functions and detailed comparisons between libraries, visit Complete C Libraries Reference section.
|
Frequently Asked Questions
Q: Why do we need a standardized development environment?
A: Standardization eliminates the "works on my machine" problem, makes collaboration easier, reduces setup time for new developers, and ensures consistent behavior across different development machines.
Q: Which compiler should I choose?
A: SAS/C 6.58 is recommended for professional development, VBCC is excellent for free/open source projects, and GCC is ideal for modern C/C++ development. All are fully supported by ToolKit.
Q: Can I use ToolKit with existing projects?
A: Yes, ToolKit is designed to be compatible with existing projects. You may need to update include paths in your makefiles to use the standardized locations.
Q: What if I don't need all the components (AmiSSL, Roadshow, etc.)?
A: ToolKit is modular - you can install only the components you need. The core NDK and compiler setup is required, but network and security components are optional.
Q: How does ToolKit help with collaboration?
A: When all developers use the same ToolKit setup, projects build identically on all machines, eliminating environment-specific bugs and making code sharing much easier.
Q: Is ToolKit compatible with Amiga 3.1?
A: ToolKit is designed for Amiga 3.2, but most components will work with Amiga 3.1. Some newer features may not be available on older systems.
Q: Is ToolKit going to support OS4?
A: OS4 has a much more comprehensive full SDK that inspired many of the ideas behind ToolKit. Where appropriate, ToolKit aims to offer a similar set of capabilities as the OS4 SDK. If and when an OS4 version of ToolKit is released it will be complementary to, not duplicating functionality of, the OS4 SDK.
Q: Is ToolKit going to support AROS?
A: AROS enthusiasts are very welcome and encouraged to contribute a similar SDK inspired by ToolKit, for AROS.
Q: Is ToolKit going to support MorphOS?
A: MorphOS enthusiasts are very welcome and encouraged to contribute a similar SDK inspired by ToolKit, for MorphOS.
Q: What additional features are coming to ToolKit?
A: To avoid empty promises, new features will only be announced when close to release, although the intention is stated above to create an automated installation of the ToolKit core features.
Q: Don't we need _git_ to be able to collaborate over the internet?
A: It is true that classic Amiga lacks a version of the git command, and even OS4 has only a very limited 'sgit' implementation. Until such time as an Amiga native build of git is available, it is suggested to do primary development on an emulated Amiga device, on projects stored on the host's shared filesystem, so that the host platform can be used for git and code editing activities, while builds can be native or cross-compiled (using vamos, or a cross-compiler build of GCC), and testing can be done on the emulated Amiga.
Q: Do you only support C?
A: The intention is to support at least C, C++ and probably Amiga E with ToolKit. After that, it depends.
Q: Why doesn't ToolKit come with all batteries included such as the NDK or C compilers?
A: ToolKit is built on open source. Non-open source components cannot be bundled with ToolKit releases.
Q: What's with the name _ToolKit_?
A: **SDK** or _Software Development Kit_ is on its own too generic a name, while the official Amiga SDK's have always been called _Native Development Kits_ or **NDK** for short. Since the Amiga Workbench metaphor describes software as 'Tools', and the suffix -Kit is common in the software development world (especially for the Cocoa/Swift platform where the SDK for every subsystem is a separate 'Kit') to describe specific type of SDK, the name ToolKit was chosen to emphasise that this is an SDK, for making Tools.
Q: What is the amigazen project?
A: ToolKit is universal developer experience produced by the _amigazen project_, which is itself an attempt to revive abandoned open source projects for the classic Amiga and Amiga-like platforms and catalyse new development by making it easier for old projects to build straight out of the box.
When inheriting legacy software the first question any professional software developer needs to know is _Does it build?_ and with long since abandoned Amiga projects the answer is often 'no it needs a bunch of missing dependencies, specific versions of include files, a bespoke configuration of compiler only found on the original developer's hard disk (currently in a landfill somewhere), and a bunch of hardcoded device volume and directory names.
amigazen project created ToolKit as a common standard for all projects to follow so that developers can be sure that if their development environment is setup for ToolKit, then other developers can easily build and contribute to their projects.
|
|
|