3.
@avra
If you take a look into CodeTyphon installation archive you can find what is minimally needed for a successful FPC source compilation.
Thank you but I'm trying to reinvent the wheel here. If I fail, I'd like to do it in a original style, like no one did it before.
2.
@marcov
make info |grep "FPC\..." (grep can of course be implemented using tprocess)
This is awesome. I didn't knew about the "info" parameter, but this opens new questions. Based on the following lines I'd like somebody to explain or check my statements:
== Package info ==
Package Name..... fpc
Package Version.. 3.1.1
== Configuration info ==
FPC.......... /usr/bin/ppcx64
FPC Version.. 2.6.4Package Name is a name of the source files.
Package Version is a version of the source files.
FPC is the compiler used to build the source files.
FPC Version is the version of the compiler that will build the source files.
If the above is right, how do "FPC" and "FPC Version" lines appear when fpc compiler can't be found, will they look like this?
FPC..........
FPC Version..Notice the empty(like '') values. Or will the lines completely miss from the output?
In windows, I see there is a full path of the compiler executable, like: "FPC.......... C:/lazarus/fpc/2.6.4/bin/i386-win32/ppc386.exe".
From where did this value came from, is make.exe searching for the compiler in the same directory where make.exe lies, is fpc related data stored within windows registry?
3.
e.g. with a fully installed release .inc files are regenerated when needed, while with a partial release a commit that only updates e.g. the ini (but not the .inc) will suddenly break.
Is the installation process of a stable fpc release doing more than the following two steps?
- extract binary and text files to a destination directory;
- configure default configuration file.
I mean is the installation process also updating the PATH or windows registries, modifying installed text files based on the installation path, or who knows what else might be done?