Re: ISO: History of this effort?

>>>>> "jhi" == Jarkko Hietaniemi <[email protected]> writes:
    jhi> Your above message is the message #6 ever, and #5 this year.

Nah, there have been more than that.  I've got at least 10 in my folder. :)

    >> or at least a web page summarizing the motivations behind its
    >> genesis as well as the evolution of those needs.  I'm trying to
    >> understand the criteria for distinguishment between perl/core,
    >> perl/sdk, and perl/other ...

Larry, I'll quote another Larry's thoughts on the matter:

    Robin Berjon writes:
    :> I recently became aware of a better way to get a list of
    :> modules and platform information using CPAN.pm in a single
    :> command...  perl -V -MCPAN -e autobundle
    :
    : That could be a pain for people that use perl on machines
    : that don't have : access to the net. I tried to see if I could
    : work around this but autobundle : wants to know which modules
    : are installed *and* accessible from CPAN, which : means that it
    : needs to connect to CPAN at least once.

    Seems to me that those are the people we're actually trying to
    develop the SDK for, so maybe we shouldn't worry too much about
    collecting data from them.  Still, if it is confusing to
    them...

    I'd like to push ahead on this--my personal interest is in
    binary CD distributions...

So the basic thrust of the sdk is to provide a mechanism for providing
a more complete perl environment to folks how may be lacking in one or
more of the things the rest of the CPAN users take for granted: net
access, compilers, supporting libraries, clue. :)

I don't think that the sdk will be *one* thing.  Rather it will be a
process that can be more or less completed as needed by someone, but
with a guarentee that wherever you stop in the process you'll have
something that works.  The process would be like this:

1. Provide a collection of modules from CPAN known to work correctly
and know to place nice with either other.

2. Provide an installation script that ensures the modules in 1. are
built and installed in the correct order.

3. Provide any support libraries needed by the collection in 1.

4. Provide (as far as possible) an installation process for building
and integrating the libraries in 3. with a perl distribution (this one
is likely to be hard).

5. Use the installation processes in 2. & 4. to provide a binary
distribution.

Working from the above, the Win32 people, the VMS people, the MacOS
people & anyone else can then add or address any platform specific
issues they may have and anyone can produce CD-ROM images (source of
binary), ftp tar balls or sand-castles as they see fit.

What's needed right now is a list of contenders for 1.

-- 
Stephen
 --- 
"If 8-year-old boys discharging loaded firearms into their own legs
isn't necessary to the maintenance of a well-regulated militia, I
don't know what is." - Randal Cummings as reported in The Onion, 25/5/99