[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

[MacPerl] XS Modules, porting, MMP




How does one submit requests to the www.pudge.net/mmp keepers?  I ask
on-list, because surely others want to do this, too.

The module in mind has an XS portion:  HTML::Parser_XS.

Some thoughts on Macs, CPAN, and XS modules...

I notice that keeping up with frequent CPAN updates is futile without
vastly more Mac manpower.  There are too many modules with binaries
getting updated too often.

What about this (he says, leaning back and dreaming of code for someone
else to write :) :

I was thinking about writing a droplet that would take a targzip file like
install, but instead look for XS files.  If it found some, it would run
them through xsubpp, then try to AppleScript CodeWarrior through making a
project, adding the files, and compiling.  [I know, this would only work
for the simplest XS projects, but suspend your disbelief for a little
while.]  It would take the shared library built, put that back into the
package, and build a Mac distribution from that.  

If the distribution was unexpectedly complex, or the compilation had
errors, or whatever else, the script could crap out with an appropriate
error message.

>From there, it would be easy to make a wrapper, so the droplet takes a URL
to a CPAN targzip file, downloads it, and does the rest.

Now, what about a CGI which takes a URL, and launches this whole process
on a net-available Mac (with MacOS 9 and remote AppleEvents, perhaps not
even the machine running the CGI).  If the module is simple enough, the
CGI starts a file download with the freshy-fresh Mac package; otherwise,
it tells the user some diagnostics.

Yet another step back, the CGI might be embedded into MMP; distributions
that are known good and available on the server can be served directly.
If a new dist is compiled and served successfully, it can be added to the
collection.

Ideally, if there were enough manpower to implement it, the compilation
script might try to handle more complicated types of builds.

The main thing is that for the simplest kind of binary module, single .XS
files, an automated tool can generate a Mac version without taking up some
porting expert's time.  When a new version appears on CPAN, the Mac
version can be quickly created.

Does this sound feasible?

One issue that might need addressing is security; sure, right now anyone
downloading a Mac binary is trusting the provider of that file.  But can
the CGI be fooled into substituting malicious code?  To get around that,
perhaps instead of a URL, the CGI would simply take a Module name, like
Text::CSV_XS.  It would go to CPAN for the module, rather than trusting a
stranger's URL.  Then, if you see the site has Text::CSV_XS, and it is
marked as submitted by the AutoPilot, then you know it is as trustworthy
as any other AutoPilot code, and came from the standard CPAN archive.

I apologize for debugging the idea on-list.  I hope this stirs the waters
of some interest.

[Side note to Chris Nandor, or whoever else is planning for the next
MacPerl release:  shouldn't/couldn't the ability to compile .XS files be
separated from the MacPerl source?  I would think this functionality could
be provided in the main MacPerl release without having to download the
full MacPerl source, or if not the main release then in a separate
download.]

Let's discuss amongst ourselves.

--
MattLangford 


# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org