Re: Dealing with XS modules on multiple platforms

IMO, I'd do something like...

have a perl server for each 'flavour' of supported OS - exporting the perl directory.
for any host, hard mount the perl directory from the appropriate server i.e. the perl server having the matching OS.

Then it becomes merely a task of running make test install on each of the perl servers - a task easily accomplished with a suitable make(1) script on one of the servers that runs make using rsh(1) on each perl server.
Moreover, the above would be simplified (almost immeasurably) if you have a central includeable (if there isn't such a word, there ought to be:-) make(1) script defining the expected/required build state in terms of modules.

In that way, you will...

Only have to build one platform specific version of the libraries
Get a scaleable solution.
Have to re-run the build iff either a module changes (version) or a new module is introduced.

HTH ,

At last, a user level that overstates my experience :-))

Comment on Re: Dealing with XS modules on multiple platforms Download Code

Replies are listed 'Best First'.
Re^2: Dealing with XS modules on multiple platforms by Mutant (Priest) on Jul 24, 2008 at 12:28 UTC
Hi. Thanks, but I'm not sure this really solves my problem. Deploying the modules is not an issue (I don't mind where they're deployed, the Perl code using them can just include the right path). I just want an easy way of building them for each platform with as little overhead and chance of making mistakes as possible. I'd also like to avoid building things as they're deployed. This can solve some of the issues, but it introduces another thing that can go wrong in the deployment process.	[reply]
Re^3: Dealing with XS modules on multiple platforms by Bloodnok (Vicar) on Jul 24, 2008 at 12:43 UTC
Hi, If my suggestion is, at least in part, acceptable, the deployment is restricted to once per platform flavour ... c/w once per consumer/user. The suggestion regarding the common includeable make(1) script presumes that the same build standard is required on all platform flavours. If the standard `make test install` fails, then you've probably got bigger worries. Note also that, without intending to be offensive, it almost sounds like you aren't aware that... the `test` target causes a build of the whole module - including any XS elements. the `install` target is attempted iff the `test` succeeds. Thus, the build is simplified ... as is the deployment and as I say, if something like the topology I suggested is employed, the amount of either is reduced. Hope that clarifies things (a bit) , At last, a user level that overstates my experience :-))	[reply] [d/l] [select]