While I completely agree with you for end user scenarios, for developers the value of having CPAN there is enormous. In the same way, something like DirectX isn't only going to give game developers the options of a) Install the end-user packages, or b) Checkout from Microsoft version control the blead version.
In comparison to these other types of major libraries, CPAN installation should (normally) provide a similar sort of role to an SDK. It provides something more thorough than a binary package, but more stable than the head of the trunk. This is where I see the SDL CPAN package. You develop initially on the CPAN version, then do packaging and testing targeting the installed/packaged/bundled/all-in-one version. Adam K 2009/9/1 David Goehrig <d...@nexttolast.com>: > Please let me attempt to diffuse what seems to ne a landline beneath a > sacred cow. > > The assumption should be that any developer is also an end user. Just > because you have mingw installed doesn't mean you know how or want to use > it. > > Same goes with CPAN. Just because it is there doesn't mean that it must be > used. Most end users prefer to use a method other cpan for installing app > and modules, such as ports apt or yum, or an msi file. > > Sdl-perl has been in cpan for 9 years and that hasn't helped much. It has > been on the backs of the deb and rpm maintainers to make everthing play > nice. And I would credit guillaume and friends for getting things packaged > and out there. > > By all means we should have a working code base in CPAN, but it is not the > correct solution for 90% of the end user / developers. This problem is not > unique to sdl-perl, it is common across all large middleware platforms. > > The model to think of is games that require the latest directx and require > you install that. > > Dave > > -=-=- d...@nexttolast.com -=-=- > > On Aug 31, 2009, at 9:39 PM, Adam Kennedy <adamkennedybac...@gmail.com> > wrote: > >> 2009/9/1 David Goehrig <d...@nexttolast.com>: >>>> >>>> What if this was fixed with Alien::SDL as it is doing for windows now? >>>> Kmx >>>> is also working on strawberry compatible makefiles. This way we can >>>> compile >>>> for most platforms from scratch. >>> >>> The problem is as Andreas originally pointed out that there are a >>> metric ton of SDL_* dlls out there, not all of which are easily found >>> in a readily accessible form for Windows. There are other issues with >>> Perl on Windows, regarding thread support, conflicts between Perl >>> threads, Windows threads, and SDL threads, but these issues are more >>> black magic stuff that really should only interest those of us hacking >>> the guts of the system. >>> >>> Alien::SDL doesn't necessarily solve your problem on this front as >>> what a Windows user / casual developer actually needs is a >>> click-wrapped installer that provides all of the necessary SDL_* dlls >>> and does not assume that they have a compiler in place. >> >> The assumption that a Windows Perl developers will have a compiler in >> place is entirely reasonable. >> >> Of the two major Perl distributions, Strawberry ships with MinGW out >> of the box, and ActivePerl has a simple "ppm MinGW" command to install >> it. >> >> In a future release, the MinGW installation will be invisible and >> silent under certain conditions, so that ActivePerl will have a >> compiler as and when it is needed. >> >> Alien:: is also named the way it is because it's designed to find >> external ways to install things, even if they are potentially strange >> and unusual. >> >> What if Alien:: itself downloaded and silently /s installed the MSI >> package? >> >> Adam K >
