[fpc-pascal] InstantFPC and argv

[Tomas Hajny]

On Mon, May 7, 2012 12:21, Mattias Gaertner wrote:
> On Sat, 5 May 2012 15:04:05 +0200 (CEST)
> "Tomas Hajny" <XHajT03 at hajny.biz> wrote:
>> On Sat, May 5, 2012 14:13, Mattias Gaertner wrote:
 .
 .
>> > ExecuteProcess is only a simple utility function.
>> > All posix platforms can start a process with another
>> > environment. By default they use the current.
>>
>> Indeed. But InstantFPC works not only on posix platforms but also on
>> WinXX
>> and OS/2 at least if I remember correctly (and there's no reason why it
>> couldn't be used even on Dos with e.g. 4DOS). All of them allow passing
>> a
>> different environment to the child process, but the implementation is
>> obviously always different. That means that you need to replicate the
>> platform specific implementation of that 'wrapper' for all supported
>> platforms within InstantFPC.
>
> The implementation for unix is only a few lines.
> I guess for winxx and os/2 too.

54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the
additional platform specific implementation for changing the passed
environment).


> I don't know about dos, but as fallback TProcess can be used, which
> already implements this x-platform.

Not yet for OS/2 nor GO32v2, but yes, this would probably be a better
option than including that stuff directly in InstantFPC if going down that
route (of changing environment for the child process).


 .
 .
>> > A const in the main script is only accessible by the program,
>> > not by the used units.
>>
>> There are obviously solutions for that. However, I assume that the main
>> use case for such scripts is writing a complete script in one file (the
>> main program).
>
> Many perl/php/python scripts use modules. I don't see why it should be
> different for fpc scripts. In fact, I already have a few shared units
> for my instantfpc scripts. The used units need a way to find out the
> current script path.

I understand that the preferences vary (personally, I'd probably compile
such a bigger executable permanently). Anyway, it may be useful
occasionally and as I mentioned, solutions exist (e.g. by defining the
interface of such modules in a way allowing to pass the location from the
main script either directly when invoking the functions having such a need
or indirectly by initializing the location by changing a variable declared
within the respective unit/module at the beginning of the script, or by
declaring the variable in the main script as external and accessing it
from the unit).

Tomas