|
|
|
Last Update: Sun Aug 14 14:57:32 2022
The CSOFT libraries and applications are covered by the MIT License. Basically, you are free to use the software however you see fit, in commercial or non-commerical applications. I only ask that, if your time and inclination permit, you report any bugs or portability problems you encounter. Suggestions for improvements and enhancements are welcome, but I do not guarantee I will act upon them.
I use the
bsd-xdr-1.0.0 library from
https://github.com/maynardGK/bsd-xdr
for platforms that don't have XDR; e.g., Windows, Android, Nintendo DS, and Palm
Pilot 68K. If you use this library, the licenses for it can be found in the
licenses
folder. (My CSOFT distribution includes the entire package, so the
licenses can be found there too, in the "bsd-xdr/licenses"
directory.)
Here is the main directory structure of the CSOFT software. The top directory,
"csoft-yyyy-mm-dd", includes the date I
created the TAR and ZIP files, thus preventing a TAR bomb
(Wikipedia)
when the files are extracted.
csoft-yyyy-mm-dd/
| (csoft.sln solution file for Microsoft Visual Studio)
|-> bsd-xdr/
| |-> lib/
| | (source, Makefiles, libxdr.vcxproj)
| `-> rpc/
| ("rpc/*.h" header files)
|-> include/
| (libgpl header files)
|-> libgpl/
| (source, Makefiles, libgpl.vcxproj)
|-> tools/
| (multiple programs: source, Makefiles, *.vcxproj files)
`-> anise/
(source, Makefiles, anise.vcxproj)
See
CSOFT README - Overview & Build.txt
for more detailed information.
Windows (Visual Studio):
csoft.sln" in Visual Studio.Note:
obj" directory,
libraries in the "lib" directory, and executables in the
"bin" directory.Linux/Unix/Cygwin (GCC):
The software can be built in-place in the source directories if desired. I always use the lndir(1) command to create a shadow directory tree with links to the source files back in the source tree. The object files, library archives, and executables are then generated in the shadow tree. For example, I have 4 shadow directories on my Linux PC, all of which link back to the source files in the source tree:
~ (Home Directory)
|-> csoft-yyyy-mm-dd/ (Source Tree)
`-> obj/ (Object Tree)
|-> android-arm64/ (Android)
|-> nds45/ (Nintendo DS)
|-> palm68k/ (Palm Pilot)
`-> x86_64linux/ (Linux)
To build the software, cd into the root of the build directory
(the source directory if building in place or the platform's object
directory) and do the following:
cd libgpl; make -f make.<platform> - builds the LIBGPL library.cd ../tools; make -f make.<platform> - builds the single-file programs.cd ../anise; make -f make.<platform> - builds the ANISE web server.
(As I go through a specific platform's directories, building the software,
I usually do an "ln -s Makefile.<platform>
Makefile", which allows me to just type "make" to build
the directory.)
Android/Nintendo DS/Palm Pilot (GCC-Based Cross-Platform Toolchains):
The build steps using these toolchains is almost identical to that for Linux, the only difference being that the BSD-XDR library is now needed:
cd bsd-xdr/lib; make -f make.<platform> - builds the BSD-XDR library.cd ../../libgpl; make -f make.<platform> - builds the LIBGPL library.cd ../tools; make -f make.<platform> - builds the single-file programs.cd ../anise; make -f make.<platform> - builds the ANISE web server.Note (Android):
To be written, but in the meantime:
My makefiles depend on the GCC toolchain, which was deprecated and
eventually removed from the Android NDK. The latest version that
I empirically found to work was NDK "r15c". (Ignore the
bizarre error messages about "libncurses.so" when the
object files are collected into the static "libgpl.a"
library.) The executables run fine on my Android 10 tablet and phone.
Someday, maybe, I'll sit down and figure out how to build under the
newer NDK versions ...
The makefiles are GNU make(1) files. See
"android-ndk-make-setup.txt"
for an explanation of the build environment I use.
My programs are command-line tools. I run them in Termux, "an Android terminal emulator and Linux environment app". (Note that the Google Play Store version is not maintained; get Termux from F-Droid or Github.) I download the executables to the device's "Downloads" directory. Then, in Termux, I copy them over to my Termux home directory and set the executable bits on the files. I was pleasantly surprised to find that the numeric-intensive programs run significantly faster on my phone and tablet than they do on my old desktop PC!
Note (PalmOS):
To be written, but in the meantime:
My programs are command-line tools. As such, after loading them on the device, they are run from and in the Palm's network log screen. Obviously not very useful, but the challenge was just sitting there for me.
I use Chuan Ji's prc-tools-remix — "prc-tools ported to modern Linux" — for the GCC toolchain.
You will also need the PalmOS SDKs for your target PalmOS version(s). Chuan Ji to the rescue, again! You'll find the different versions at palm-os-sdk. (He also has some additional PalmOS-related tools in other repositories.)
The makefiles are GNU make(1) files. See
"palmos-prc-make-setup.txt"
for an explanation of the build environment I use.
There are some PalmOS-specific header files in
"include/palmos/*". Most of them are normal Linux system
header files that simply #include the corresponding but
differently named SDK headers.
... ROMs and emulator (POSE) ...
Last Update: Sun Mar 20 23:01:30 2022