|
|
|
Last Update: Sun Sep 8 22:27:18 2024
See
CSOFT README -
Overview & Build.txt for more detailed
information.
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.)
I use a version of Stephan Brumme's "Fastest Bitwise CRC32" function in my ID3 code (id3_util and tag311). The table-less, branch-free function is not speedy, but it is very compact. The code's license follows the zlib License.
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)
`-> cornet/
(source, Makefiles, cornet.vcxproj)
csoft.sln" in Visual Studio.Note:
obj" directory,
libraries in the "lib" directory, and executables in the
"bin" directory.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)
|-> ndk-aarch64/ (Android)
|-> nds45/ (Nintendo DS)
|-> palm68k/ (Palm Pilot)
|-> x86_64cygwin/ (Linux)
`-> 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.cd ../cornet; make -f make.<platform> - builds the CORNET client.
(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.)
The build steps using the respective platforms' cross-compilation 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.cd ../cornet; make -f make.<platform> - builds the CORNET client.
where platform is "ndk" for the Android NDK,
"nds" for the Nintendo DS, and "palm68k"
for PalmOS (m68k only).
To be written, but in the meantime:
My software is build for Android using the Android NDK cross-compilation toolchains (CLANG-based).
The makefiles are GNU make(1) files. See
"include/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!
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: Fri Nov 1 22:39:54 2024