At 04:29 AM 11/14/2002 +0000, Soren A wrote:
As noted previously, I don't know exactly what your problem domain is and I don't use Cygwin myself so what I say cannot be directly antagonistic to your position. However, I can't help but feeling that you're rushing to judgement because what you really want is to release your own module on your own terms because it does something you already have an investment in. And I'm not sure you've sufficiently researched File::Spec. For instance, casting pathnames into the current platform's native format is not the only thing File::Spec does, it's merely the *default*. E.g., say I'm on Windows (with no Cygwin). The locutionI don't think that what my proposed module does is a good fit with the domain of File::Spec. You can already use File::Spec to get an absolute path on Cygwin Perl (for example); you just cannot get it to give you that path in any other *mode* than POSIX. But the outer environment in which Cygwin is running is *not* a POSIX kind of OS and its applications (and shells) don't understand POSIX file specs.
File::Spec->rel2abs($path);
will return an absolute pathname in Windows form. But saying
File::Spec::Unix->rel2abs($path);
will put it in a locally-valid Unix-style form. I still don't know exactly what you need that can't operate within this framework.
Perhaps you're not familiar with how CPAN and modules work? The fact that File::Spec 0.83 is bundled with Perl 5.8.0 does not mean that you must upgrade to 5.8.0 to get it. On the contrary, it's simply a convenience for people using 5.8.0 and up. Others can download it from CPAN and install it, just exactly as they would have to do with your new module. If you came to an agreement with its author to add functionality which appeared in, say, version 0.84 anyone wanting those features would have to download and install, again just as they'd have to do with a Filesys::CygwinPaths module. If your potential users aren't able or willing to install a new *module* then you're SOL either way.A couple of additional points relating to the above are that while Perl 5.8.x may have additions to include greater Cygwin-specific code, 5.6.x (I am developing on 5.6.1) and earlier will not. I'd like to release something that could benefit those who for whatever reason aren't able or willing to upgrade right away.
Look, the standard advice (paraphrasing) is "rather than adding yet another module with your cool new features, see if you can hook up with the maintainer of an existing module and improve it". The standard advice is sometimes wrong, but the burden of proof is on you to do the due diligence and show that this is such a case.
I write a lot of Perl code that has to interoperate between Windows and Unix and thus I spend a lot of time dealing with issues of shell quoting, pathname styles, etc. I've had to try to handle hybrids (more MKS than Cygwin) in that context, and having all the know-how built into a single module such as File::Spec is a great help in writing portable applications. In other words: from the point of view of someone whose commitment is to the environment (Cygwin) and "just wants it to work", a Filesys::Cygwin module may feel like just the thing. But from the point of view of someone whose commitment is to a solution (a piece of software) and who wants it to work in as many environments as possible, it's exactly the wrong thing.
Which brings up an ancillary point. Wouldn't most of the same pathname issues apply to MKS or U/Win or any other Unix-on-Windows environment? Again, why should I, as the maintainer of an application, have to micromanage the (barely visible) distinction between MKS and Cygwin paths and download/build XS modules just in order to do so? I can tell you that I'd do just about anything, which includes tormenting File::Spec or subclassing it within my own application, to avoid this fate.
You may think File::Spec is limited and ignorant. However, I've corresponded with its maintainer and I can assure you that he's anything but. So I think you should at least get in touch with him and see if he thinks any synergy is possible.
What you're doing requires XS code? It's hard to see how something as simple as path normalization would, but if it does (presumably you're hooking into a Cygwin DLL?) then that's a good argument for doing it your way. In fact if this is the case I'd skip all the other arguments if I were you and just say "it's an interface to a Cygwin DLL, hence it only makes sense or could compile for Cygwin users, thus it should be off in its own Cygwin corner". I would not argue with that line, though I'd still wonder why a pure-perl, MKS-compatible solution wouldn't be better. And is it not conceivable that someone might want to create Cygwin-style paths from a platform other than Cygwin?Also, say my module's functionality was to be added to the File::Spec::Cygwin module. Would it be distributed as part of that bundle? It's going to add a non-trivial amount of weight (filesize, complexity) to the package. There's XS code to be selectively processed but only on the Cygwin platform (Makefile - build-config complexity introduced), etc. I'm extremely unsanguine about attacking that sort of task (the support of it).
Ok, this is what I was missing. It *is* an interface to a Cygwin DLL. If in your consideration the Cygwin DLL really adds enough value to justify the environment-specific XS glue and overhead, then I withdraw my above criticisms as "potentially good points but on the wrong topic".OTOH, I am not at all unenthusiastic about the idea that the pieces I've introduced -- the interface to the Cygwin C API is the core of it
-David Boyce
