Hi Radek, rahed schrieb: >> The problems with this approach can't be ignored, though: a) I'm >> not entirely sure what I did conforms to the license of InfoZip. I >> think so, since I left it basically untouched, but I'm not a >> lawyer. > > I'm not an expert but looking at their license roughly I don't see it > is forbidden to reuse their code.
I agree. In particular since I'm leaving it unmodified and since I'm not claiming to have the same interface and call it InfoZip. >> c) unzip is portable, but my Makefile(.PL) hackery isn't. It would >> probably take someone who is better at XS (or Makefiles) to do this >> right. Additionally, I could only test the module on linux (32 and >> 64bit). *I really need somebody to fix it up on win32 and/or >> MacOS!* > > I could test it on windows but I think I'm not of much help with XS. The XS wrapper itself is trivial. The real magic is happening in the Makefile.PL's in the main distribution directory and the res/ subdirectory. Just testing the distribution would be of much help. In case there are problems which you don't find a workaround for, it would be great if you could do the following: (Quoting a mail to Philippe Schaffnit) If one of the OS's fail, please try the following: > 1) Do a fresh tar -xzf > 2) cd() into the res/unzip-5.52 directory > 3) copy the correct Makefile from the architecture specific > subdirectory to res/unzip-5.52 > 4) type make to see what targets are available > 5) Try to make some kind of shared library target > 6) Do an ls -l > 7) Send me the name of the Makefile, the name of the target, and the > output of ls -l > 8) I'll see what I can do with that. > > Of course, you're welcome to look into the two Makefile.PL (in the > main dir and in res/) and try adding a special case for the failing > OS yourself. In particular, I suppose the object files might differ > from OS to OS and my simple hack doesn't cater to that well enough. Thanks for your help! Steffen
