Re: Building on Win32 - the real problem

Ages ago all of the xs code was broken out into separated files. We  
switched over to a monolithic build with conditional compilation due  
to the problems of maintaining coherency in the face of nested  
dependencies.

One of the things the old build scripts did that the new pseudo-cpan- 
friendly ones do not was it prompted you as to what would be built and  
gave you an option to fix the dependencies.  Since some SDL addons  
require other SDL addons it is important to make sure you link against  
the same versions of each lib.

I would argue the correct solution is to require all deps by default  
with an option not to load at run time. The reason to this is when  
packaging a distro you want a standard package to build against. Hence  
the kitchen sink approach.

If I apt-get sdl-perl I would want the full install. If I'm  
engineering a resource constrained device I am already assuming enough  
effort to make making a cut down build worth my while. At which point  
the monolithic should still just work.

I personally perfer to make design decisions that meet the needs of  
the 90% of users who are just expecting it to just work. The other 10%  
you can never please anyways :)

Dave

Ps we by definiton are in that 10%. So our opnions don't count.


-=-=- [email protected] -=-=-
On Aug 30, 2009, at 4:48 PM, chromatic <[email protected]> wrote:

> On Sunday 30 August 2009 00:45:15 Andreas Lund wrote:
>
>> Yet again I have decided to try building SDL on Win32 and yet again  
>> I have
>> not even made it to the actual building. Why? Because only about  
>> half the
>> required libraries can be downloaded for Windows.
>
> That brings up a good point.  SDL_perl 2.x builds a monolithic XS  
> which
> attempts to link against plenty of SDL-related libraries, such as  
> SDL_ttf and
> SDL_gfx.
>
> Even though distribution becomes slightly more complex, I suggest that
> SDL_perl 3.x build separate XS files for these supplementary  
> libraries.
> Perhaps they could even be separate CPAN distributions.
>
> It might be worth considering something similar for the OpenGL  
> components as
> well.
>
> -- c