On Mon, May 7, 2012 12:21, Mattias Gaertner wrote: > On Sat, 5 May 2012 15:04:05 +0200 (CEST) > "Tomas Hajny" <xhaj...@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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
