Started this, this morning before any of 'today's emails...just never
finished it..
Seems pertinent with the talk of alternate packages that only work with
alternate
compilers -- especially those that are limited in the platforms they
support (Gnu is on
Linux, Windows, Mac, Solaris, Irix, et all...)...
Dana Hudes wrote:
Solaris Perl is compiled using the Sun C compiler since at least Solaris 8.
Once known as Forte now Solaris Studio.
IDK what Perl on Moc OS X is compiled with but suspect not gcc. A LOT of people write Perl on Mac.
Could you defined 'LOT' in terms of % of perl market? If modules
written ON the MAC will be generally useful to MOST PERL programmers,
then -> main index. Else if only useful to Mac perl users, -> Mac:: world.
BTW -- equally comfortable with them taking a name like "Dirlister::Mac"
-- if they want to provide a top level "Dirlister" for their functions,
that's acceptable, only if they acknowledge that 'Dirlister doesn't
belong to the Mac, and the top level interface is subject to _change_
based on design _needs_ ( if it wasn't created to be sufficiently
general in the same calls for other platforms) AND be open to having new
functions ADDED for support of new functions/features in the module that
might be pertinent on other platforms. Examples:
Good examples: File::Path, Path::Class -- both are platform
agnostic.. File:Path, *explicitly*,
has platform specific submodules for various OS types: Unix Mac, OS2,
Win32, VMS.
Bad example: Path::Abstract -- is unix specific. should be
Path::Abstract::Unix, in fact says:
"Path::Abstract is a tool for parsing, interrogating, and modifying
a UNIX-style path. The parsing behavior is similar to
File::Spec::Unix
<http://search.cpan.org/perldoc?File%3A%3ASpec%3A%3AUnix>, except
that trailing slashes are preserved (converted into a single slash)."
So the author took a Unix function, duplicated it and called it by a
general name, Path::Abstract...how thoughtful is that? If the top level
interface supports the ability to make it generic, then if someone
wants to add another platform: Path::Abstract becomes shared. and that
author gets Path::Abstract::Unix.
Later on, if their Path::Abstract::Unix isn't general for Unix, but only
runs on say, a System-V derivative,
(Solaris, Irix, linux) and someone comes along with a version that
supports BSD derivatives (SunOS, MacOS), similarly, they need to be
willing to move their original code into
Path::Abstract::Unix::SysV[/BSD]. and have
a top level Unix that calls their code or 'the other code'...
If things are done 'right' at the design phase, the above should be a
no-brainer --
($ostype =~ /Aix|Bix|Cix/) and goto &__PACKAGE__::SysV; ..... etc...
AT this point, it should be obvious to anyone, that things like the
above can't be monitored from the top down -- in fact, if no one wants
to use Pth:Abs" on another platform, nothing would need to change,
Only if 'room needs to be made'...
Note, this SAME problem used to be a problem with just supporting
multiple VERSIONS of the same modules! (ex.
http://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/200406.mbox/<87n02u6o1x....@gemini.sunstarsys.com>
)
http://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/200406.mbox/<87n02u6o1x....@gemini.sunstarsys.com>
(http://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/200406.mbox/%3c87n02u6o1x....@gemini.sunstarsys.com%3E)
Not everyone runs Linux. It is completely legitimate to have CPAN modules which were not even tested on Linux.
100% agree!
You may not find their code of interest but to decide it is of no value if it
doesn't run on Linux is not terribly clueful.
Yup... I'm bi-platform @ home, Windows frontend, and linux backend...
I've used SunOS/Solaris/Irix, and worked at Sun/Sgi)... ...
I point to the IMHO nice useful Solaris namespace modules on CPAN.
----
Ding Ding Ding... give the solaris folks a prize...(not being
sarcastic!)... see below)...
Having modules that are platform specific, should be either
1. ***minimally***, clearly labeled in descriptions, AND, CPAN
should allow me to exclude modules that won't run on on the
platform's i select. Having a module that only runs on DEC's
Tops-10, doesn't do many people very much good. I question it's
usefulness in being listed in a general directory of modules.
2. Unless it runs on at least 1 or more dominant platform where perl
runs, it shouldn't be listed without an OS/ARCH suffix. If it is
a generic unix OS type function, it should at least run on linux
or some free BSD version. If something was 'Cygwin' only, should
be labeled such. Or if such is Win32 only should be labeled such
(aren't most?)
It seems like most of the Win modules have gone the right direction.
How surprising, that Windows
developers might be clear about what platform their module is designed
for. Are developers for other platforms less capable than Windows
developers?
If a module won't run on a standard posix compliant system, using
standard posix compliant tools, is there a reason why it shouln't have a
'Mac::' or 'Android::, or 'iPhone' specific prefix (as random examples)?
=====
So YEAY, if solaris has already done that... they aren't
contributing to the main problem space.
(if their modules are broken, only affects other Solarians... ;-)....
I don't run Linux: windows at home, Solaris 8, 9, 10 and 11 at work. My
personal web space is some Linux variant with a broken gcc and bespoke broken
Perl -- they tend to heavily favor PHP.
----
Win7 & suse linux... linux does server type stuff... win7 plays
client..... always a chore making them play nice...
Note -- on the specialty compilers -- if they are designed for a
platform and it is already under its own namespace, then .. I don't see
that as being a big problem.
But let me re-iterate the statement which at least _some_ of N.Clark's
items DON'T qualify on (haven't checked
them all out)...
1. What compiler on linux -- that supports nearly the same
environment as that which gave birth
to Perl (sed/awk,shell, grep/sort/...etc)".., that is as freely
available as Perl and the modules on CPAN
(freely available regarding restrictions of use as well)... would you
suggest I used?
2. In general, as was pointed, out, since Windows is also widely
used with Perl, the same compiler
should also be available there as well. I didn't ask for an
exhaustive list, one compiler that produces as good as [code] and
supports 32/64 bit linux and windows (all settle for 64 bit only)... but
having runnable under cygwin would be useful as it is a posix environment...
Oh how ratholed/derailed this day's verbiage has been.
