Installing Husky ================ Contents -------- 1 Introduction 2 Installation Using Universal Makefiles 2.1 Before Starting Husky Build 2.2 Build Configuration with `huskymak.cfg` 2.3 Installing Husky on Rpm-based Linux Distributions 2.4 Installing Husky on Other UNIX-like Operating Systems 3 Compiling with the Legacy Makefiles 3.1 Overview 3.2 Getting the Sources 3.3 List of Platforms Supported by the legacy Makefiles 3.4 Compiling 3.5 Installing 1 Introduction ============== *Husky* is a set of programs for processing incoming messages and files according to Fidonet standards. Here's how to install Husky. You can use two types of makefiles for installation. Universal makefiles allow installation in different operating systems due to the presence of the configuration file `huskymak.cfg`. Makefiles of the second type (legacy ones) are intended for a specific operating system. Husky software version numbers consist of three integers separated by dots, for example, 1.9.20210827 Here, the last number is the date when the last change was made to the source code of the program. The date consists of a sequentially recorded year, month, and day. 2 Installation using universal makefiles ======================================== To configure the build using universal makefiles, use the *huskymak.cfg* file. But before you start downloading the sources, you have to install some programs you will need during the build. We assume you have version 3.81 or newer of GNU make installed. 2.1 Before Starting Husky Build ------------------------------- The tables below list the software packages you should install before building Husky on the most common operating systems. These tables also record the conditions under which you will need these packages. Red Hat Enterprise Linux, CentOS, Fedora, Rocky Linux Package What requires the package ------------------------------------------------- git getting the sources and updating them make, gcc, gcc-c++ build from sources perl-ExtUtils-Embed hpt at PERL=1 zlib, zlib-devel hpt, htick at USE_HPTZIP=1 zlib-static hpt, htick at USE_HPTZIP=1 and DYNLIBS=0 texinfo hpt, htick, msged at ((HTML=1 or TXT=1 or PDF=1 or DVI=1) and defined DOCDIR) or defined INFODIR texinfo-tex hpt, htick, msged at (PDF=1 or DVI=1) and defined DOCDIR ncurses-devel msged perl-Module-Build, util perl-Test-Simple Ubuntu Package What requires the package ------------------------------------------------- git getting the sources and updating them make, gcc, g++ build from sources libperl-dev hpt at PERL=1 zlib1g, zlib1g-dev hpt, htick at USE_HPTZIP=1 texinfo hpt, htick, msged at ((HTML=1 or TXT=1 or PDF=1 or DVI=1) and defined DOCDIR) or defined INFODIR ncurses-base, msged ncurses-bin libmodule-build-perl, util libtest-simple-perl FreeBSD Package What requires the package ------------------------------------------------- git getting the sources and updating them gmake build from sources libperl-dev hpt at PERL=1 zlib1g, zlib1g-dev hpt, htick at USE_HPTZIP=1 texinfo hpt, htick, msged at ((HTML=1 or TXT=1 or PDF=1 or DVI=1) and defined DOCDIR) or defined INFODIR texlive-full hpt, htick, msged at (PDF=1 or DVI=1) and defined DOCDIR p5-Module-Build, util p5-Test-Simple 2.2 Build Configuration with `huskymak.cfg` ------------------------------------------ The configuration file `huskymak.cfg` contains the settings used during the build of Husky programs. You may change these settings according to your needs. All lines starting with a `#` are comments. The settings look like variable=value There are two types of settings. In the settings of the first type, the value is a string of characters. If the setting is commented out, the value of the variable is undefined. The second setting type is a switch. Here the value can be *0* or *1*. The value of `1` means "on" and `0` means "off". For example, if you want to use Perl hooks in `hpt`, set PERL=1 Otherwise, set PERL=0 If a setting of the second type is commented out, it is equivalent to its value of *0*. 2.3 Installing Husky on Rpm-based Linux Distributions ----------------------------------------------------- To build rpm packages, you need to install *mock* in addition to GNU make and compilers. Mock uses _chroot_ for the build, which isolates the build environment and guarantees reproducibility of the result. If mock is not available in your distribution, you must at least install *rpmbuild*. The script used for installation will use mock if it is installed, otherwise rpmbuild will be used. To start the installation, do the following: wget https://raw.githubusercontent.com/huskyproject/huskybse/master/script/init_rpm_build chmod 0755 init_rpm_build ./init_rpm_build As a result, the `~/husky_build` directory will be created, and the `husky` directory will be in it. Husky sources will be downloaded to this `husky` directory. But now we are interested in the file `huskymak.rpm.cfg` lying in this directory. This is the very build configuration file that you need to view and, possibly, change something in it. Please note that it is necessary to edit `huskymak.rpm.cfg`, and not `huskymak.cfg`. You may notice that DEBUG=1 It is not an error, and it is not necessary to redo it to `DEBUG=0`. Modern compilers can combine compilation with debugging and optimization. As a result of the build, you will get executable files with the debug symbols stripped, and the debugging information will be contained in a separate package that you can install if debugging is necessary. You will perform all the steps described above only once. Now you can start the build: ~/husky_build/build_rpm If you have `mock`, you may find the result in the directory `~/husky_build/result`. If you have no `mock`, the result is in the directory `~/rpmbuild/RPMS`. If you used the recommended value DYNLIBS=0 the names of the built packets will contain the word `static`. It means that a partly static build was used, in which the Husky libraries were linked statically, and the system libraries were dynamic. Later, when you find out that changes have been made to the source code, and want to build a new version, it will be enough to run again ~/husky_build/build_rpm It will download all changes from GitHub and rebuild all packages. If you want to build packages for another operating system using `mock`, run ~/husky_build/build_rpm -r 'CONFIG' where CONFIG is the chroot configuration. See `build_rpm --help` and mock(1). You may also find some additional options for `build_rpm`. See `build_rpm --help`. 2.4 Installing Husky on Other UNIX-like Operating Systems --------------------------------------------------------- To start the installation, follow these steps: wget https://raw.githubusercontent.com/huskyproject/huskybse/master/script/init_build chmod 0755 init_build ./init_build These commands are for Linux. On FreeBSD, write `fetch` instead of `wget`, the rest is the same. As a result, the `~/husky` directory will be created. Husky sources will be downloaded to this directory in the future. But now we are interested in the file `huskymak.cfg` residing in this directory. This is the very build configuration file that you need to view and, possibly, change something in it. If you previously cloned the Husky repositories from GitHub into a directory with a different name, run `init_build` this way: ./init_build -d YOUR_DIRECTORY where `YOUR_DIRECTORY` is the name of your directory. This option can also be used if the `~/husky` directory is already occupied by something else, for example, there are photos of your beloved dog there. So you downloaded `init_build`, ran it, read `huskymak.cfg` carefully and corrected it according to your needs. You have to perform the actions only once. If in the future you want to build a new Husky version, you will not need to repeat the steps. Now you can start the build: ./build.sh It will build the programs listed in PROGRAMS in the file `huskymak.cfg` and the libraries they depend on. After the build is complete, you may install the built programs. If you have set PREFIX variable in your huskymak.cfg to some directory in your HOME, to install everything on Linux run make -j install and on FreeBSD gmake -j install Otherwise, on Linux run sudo make -j install and on FreeBSD env SHELL=/bin/sh sudo -s gmake -j install Here, the `-j` option sets the parallel execution. Before you start using the installed Perl utilities, it is important to consider whether the directory where the Perl modules are installed is in `@INC` array. If you used `PREFIX=/usr/local`, you have nothing to worry about. Otherwise, the directory with Perl modules is `$PREFIX/share/perl5`. To compare it with members of @INC array you first have to manually substitute `$PREFIX` with the value you have set for it in your `huskymak.cfg`. `@INC` is displayed at the end of the output from the command perl -V You may not bother to look at @INC if you have set `PREFIX` to a subdirectory of `HOME`, since in this case `@INC` definitely does not contain `$PREFIX/share/perl5`. If `PREFIX` is a subdirectory of `HOME`, you have to set and export `PERL5LIB` environment variable. On Linux with the default bash shell add the line to your `~/.bash_profile`: export PERL5LIB=$PREFIX/share/perl5 in which you manually substitute `$PREFIX` with its value. On FreeBSD you have to add this line to `~/.profile`. You also have to add `$PREFIX/bin` to `PATH` if the `PATH` does not contain `$PREFIX/bin`. If your `PREFIX` is not a subdirectory of `HOME` and `@INC` does not contain `$PREFIX/share/perl5`, you have to add the line exporting `PERL5LIB` to `/root/.bash_profile` on Linux and to `/root/.profile` on FreeBSD. If `@INC` contains `$PREFIX/share/perl5` directory, you have to add nothing. If you want to uninstall the installed programs, on Linux run sudo make -j uninstall and on FreeBSD env SHELL=/bin/sh sudo -s gmake -j uninstall If you want to delete all the built results, run make distclean (Linux) gmake distclean (FreeBSD) But keep in mind that if you deleted all the build results, you will have to repeat the entire build next time. Later, when you find out that changes have been made to the source code, and you want to build a new version, it will be enough to run again ./build.sh This will download all changes from GitHub and rebuild all the changed programs. You may also find some additional options for `build.sh`. See `build.sh --help`. 3 Compiling with the Legacy Makefiles ===================================== 3.1 Overview ------------ Besides the standard `Makefile`, most Husky modules deliver additional makefiles, named "makefile.XXX", where "XXX" is a platform-dependent suffix. We call such makefiles legacy. If we compare legacy makefiles with the standard one, here's what can be said for and against legacy makefiles. For: - You don't need to edit huskymak.cfg, the makefiles have no additional configuration. - Many non-UNIX systems are supported. - You need neither GNU make nor gcc if not specified otherwise. - Sometimes they give less trouble than the standard Makefile. Against: - You cannot (usually) install anything with these makefiles. It is within your responsibility to copy the programs that you compiled to the proper directories. - No support for shared libraries, everything is linked statically. - Legacy makefiles do not create `cvsdate.h` files containing the last modification date of the source code. You need to create these files yourself. 3.2 Getting the Sources ----------------------- The Husky Fidonet software project is split into several subprojects. A subproject is a library or a program. In order to compile any Husky program, you will at least have to download the following subprojects: huskybse Husky Base, contains instructions and sample configs. huskylib Common declarations and functions for Husky programs smapi The Squish and Jam Message API library. fidoconf The Fidoconfig library. areafix The Areafix library. In addition, you need the programs that you want to use, like `hpt` (the tosser), `htick` (the ticker), `msged` (the mail editor), and others. The Areafix library is only needed for `hpt` and `htick`. Since the sources are on GitHub, you have to use git to get them. For any subproject here is the command to get it: git clone https://github.com/huskyproject/subproject.git Here `subproject` is the name of some subproject. So, mkdir ~/husky cd ~/husky git clone https://github.com/huskyproject/huskybse.git git clone https://github.com/huskyproject/huskylib.git git clone https://github.com/huskyproject/smapi.git git clone https://github.com/huskyproject/fidoconf.git git clone https://github.com/huskyproject/areafix.git git clone https://github.com/huskyproject/hpt.git git clone https://github.com/huskyproject/htick.git The `git clone` command should only be used for the first time. The next time you want to build a new version of programs, use `git pull` to update the source code: pushd SUBPROJECT_NAME git pull popd After downloading the source code and after each update, you need to re-create the `cvsdate.h` files containing the date of the last modification of the source code. In all subprojects, except for `hptsqfix`, this file is located in the root directory of the subproject, and in `hptsqfix` it is located in the `h` subdirectory. The content of the file `cvsdate.h` is as follows: char cvs_date[]="2021-09-03"; Here `2021-09-03` is an example of the last modification date of the subproject source code in ISO 8601 format. Naturally, you will have a different date. There should not be any spaces or tabs at the beginning of the line. The date of the last modification of the source code of the subproject can be obtained with the command git log -1 --date=short --format=format:"%cd" h/*.h src/*.c The names of the directories containing the files `*.h` and `*.c` may differ. It is also necessary to consider the dates of the last modification of the source code in the subprojects that are dependencies of this one. For example, `hpt` depends on `huskylib`, so if `huskylib` was changed after `hpt`, then for `hpt` you need to take the date from `huskylib`. The maximum date of the last change to the subproject itself and all of its dependencies should be taken as the date in `cvsdate.h`. 3.3 List of Platforms Supported by the Legacy Makefiles ------------------------------------------------------- The following is a list of platforms that are supported by legacy makefiles. Makefile Platform Compiler --------------------------------------------------------------------- makefile.unx Unix Any (standard "cc" is enough!) makefile.be BeOS BeOS R5 with gcc makefile.bsd BSD (tested: FreeBSD) GNU gcc makefile.lnx Linux GNU gcc (2.7..2.95, 3.x) makefile.djg DOS/32 DJ Delorie GNU gcc (DJGPP) makefile.cyg Win32 Mingw32 on Cygwin: http://www.cygwin.com makefile.mvc Win32 Microsoft Visual C makefile.mvcdll Win32 Microsoft Visual C - dll build makefile.emo OS/2 EMX; OMF static (standalone) binaries makefile.emx OS/2 EMX; a.out dynamic (EMXRT) binaries makefile.mgw Win32 Mingw32 or Mingw32/CPD gcc: www.mingw32.org makefile.rxw Win32 EMX/RSXNT gcc with -Zwin32 makefile.sun Solaris GNU gcc makefile.wco OS/2 Watcom C makefile.wcw Win32 Watcom C makefile.wcx DOS/32 Watcom C with DOS extender makefile.aix AIX IBM xlC makefile.bcd DOS Borland C / Turbo C (requires TASM) makefile.bco OS/2 Borland C 2.0 makefile.bcw Win32 Borland C makefile.ibo OS/2 IBM CSet or VACPP makefile.hco OS/2 Metaware High C makefile.osf TRU64 Compaq CC (or DEC Unix with DEC cc) makefile.wcd DOS Watcom C makefile.qcd DOS Quick C / Microsoft MSC 6.0 (req. MASM) As a rule of thumb, if you have any Unix OS with a `make` and a `cc` command, you should first try to use `makefile.unx`. `makefile.unx` is a very troublefree way of building everything! 3.4 Compiling ------------- Now that you have chosen the proper makefile, build the libraries like this (let's assume you have chosen makefile.unx): cd ~/husky/huskylib make -f makefile.unx clean make -f makefile.unx cd ~/husky/smapi make -f makefile.unx clean make -f makefile.unx cd ~/husky/fidoconf make -f makefile.unx clean make -f makefile.unx cd ~/husky/areafix make -f makefile.unx clean make -f makefile.unx You can then directly proceed to build any subproject like this: cd ~/husky/SUBPROJECT_NAME make -f makefile.unx This also works with Non-UNIX systems, e.g.: C: CD \HUSKY\HUSKYLIB imake -f makefile.ibo clean imake -f makefile.ibo CD \HUSKY\SMAPI imake -f makefile.ibo clean imake -f makefile.ibo CD \HUSKY\FIDOCONF imake -f makefile.ibo clean imake -f makefile.ibo CD \HUSKY\MSGED imake -f makefile.ibo clean imake -f makefile.ibo 3.5 Installing -------------- As already noted, the legacy makefiles usually do not contain an "install" target. Therefore, you have to "install" the programs manually if you use legacy makefiles (you don't need to install the libraries, as the programs are linked against those statically). For most Husky programs, installing is just copying the executables to a directory of your choice. For some others, it is more complicated, in particular Msged, where you must also install the recoding tables, help files, etc. Please refer to the individual programs' documentation for more information.