On Friday, June 13, 2003, at 03:58 PM, perl_beginner wrote:
Hey All,
Thanks folks for all the pointers,
From the replies so far, I see two approaches. I need to work with
files/pathnames through portable perl modules. This means I don't have to
actually perform any OS-specific work before installation of the
application.
This is definitely the way to go, in my opinion.
As I go through the documentation for MakeMaker, couple of questions come
up at this stage, is the objective of ExtUtils::MakeMaker to actually
resolve OS specific issues at Install time? I maybe wrong, but it appears
to me:
1. It is preferred to write portable code which does not have to be
tweaked at installation time. That leaves the primary objective of the
initial Makefile work to simply build binaries. Doing the dirty work of the
developer to generate platform-dependant code IS (as per good practice) NOT
it's domain.
Sure, I would always rather maintain one codebase, wouldn't you?
2. A more specific question, is this the right way to handle code that
works on Linux and:
a. "forks" a process (won't work on Win environments)
Perl emulates fork() on Windows in version 5.6 and up, if I'm not mistaken.
b. Handles OS Signals like $SIG{ALRM} (- as above -)
Programming Perl and perldoc perlport both do seem to warn against this one, but I don't know much about it. Maybe someone will suggest a workaround.
James
I will RTFM while these questions remain open... all the same your thoughts are welcome.
Finally, I changed my code to work with File::Spec and File::Copy. I commented out the signal handling part. There is nothing else platform-specific. I tried taking my server to Windows XP.
While the code works fine with Linux, crumbles on XP saying "Can't find
string terminator "EOM" anywhere before EOF at recordProxy.pl line 317".
Line 317 in my code is: $response= <<"EOM";
I get the feeling that this is a more general class of errors which is why
I mention it on the list. (No ;-) I don't expect anyone to debug my code).
If anyone has any comments on this error they are most welcome, I shall
continue working on trying to identify what's wrong.
Thank you for your time and your kind attention...
Best Regards, Santosh Dawara
------- Original Message -------From: John W. Krahn <[EMAIL PROTECTED]> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Subject: Re: Writing Platform Independant Perl Code Date: Fri, 13 Jun 2003 12:06:37 -0700
Perl_beginner wrote:
Hello all,
Hello,
I have finished writing up a neat Perl server which works just fine on Linux. I want to see it work seamlessly on other platforms too (Windows/*Nix)
perldoc perlport perldoc perltrap perldoc perlwin32 perldoc perl[your operating system]
The first issue that I see, is with people who want to use my server on Windows. Directory seperators ('/' -> '\\') have to be changed before the script can be run on Win32. Or atleast I think that is the case.
No, that is not the case. The Windows shell (command.com) requires the
separator to be '\' however perl "talks" directly to the OS which allows
the use of '/'.
From past experience, I know that several perl modules come with a Makefile.PL or atleast some way whereby the user can: 1. Unpack the code delivered 2. Specify his platform and execute some script 3. The script preps the code for the platform 3. User can now use the customized application
I have no idea how to go about doing this! Any pointers or resources would be helpful.
perldoc ExtUtils::MakeMaker
The second issue, How do I keep pathnames platform independant. This precludes the necessity of writing a solution to install the application on the users machine. Please note that the application accepts some pathnames as command-line parameters.
The modules in the File hierarchy should be portable.
perldoc File::Basename perldoc File::Spec perldoc File::Path perldoc File::Glob etc.
John -- use Perl; program fulfillment
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
