Well porting command line stuff really is described best as a branch of compiling software from source. As expected this requires a tool chain with a compiler (gcc) headers, and libraries. Headers are nothing more than a "what this library" is capable of type reference, and is written in C, and Libraries are binaries that are pre programmed "tasks" to automate otherwise receptive tasks.
That being said, compiling most *niz software boils down to a few steps.
./configure
make
make install
Some projects also come with a test suite to ensure that the program compiled correctly. This is typically invoked with
make check
Now to dive into what this is,
./configure runs a script to set all kinds of environmental variables to help ensure successful compilation of the package, typically by creating a Makefile. Additionally the configure script will point out missing dependencies. A verbose log of what configure is doing is saved as config.log.
Make reads a Makefile, and runs gcc with the options to compile the source code into the binaries, keeping all files in the local directory, or sub directory.
Make install tells make to copy all the binaries to the standard location for binaries on the system (typically /usr/bin or /usr/local/bin)
The final (optional) step is to run make check, which run the newly compiled binaries through a test system to ensure they are working properly.
That all is compiling, a break down of something not working at any one of those steps is when the process turns into porting.
I will happily expand on this response if you provide more direction...hopefully this provides you with enough terminology to ask your question effectively.
