in reply to Re^2: Disputation of g0n on the power and efficacy of XS
in thread Disputation of g0n on the power and efficacy of XS

Those things have never seemed especially hard for me. Just how easy do you want things to be?

I'm not sure why you have to track down expat: it's not tough to find. There are even binaries for AIX (which I found by Googling "expat AIX" and following the top link).

I'd rather not have expat as part of XML::Parser. I'll download the latest version and compile it myself. The current version of expat doesn't have to get out of step with the one that would get locked in with a version of XML::Parser. I can even update them separately.

Installing libraries isn't that hard, and installing a C compiler isn't that hard (although it can be lengthy). Distributing them with the modules isn't going to make that any simpler.

The original post complains that we even deign to use something written in C, and correctly says that if you don't like it, you can upload the pure Perl version to CPAN. I'd rather just use what other people have already than reinvent the wheel. :)

--
brian d foy <brian@stonehenge.com>
  • Comment on Re^3: Disputation of g0n on the power and efficacy of XS

Replies are listed 'Best First'.
Re^4: Disputation of g0n on the power and efficacy of XS
by Tanktalus (Canon) on Apr 21, 2005 at 04:15 UTC

    I think you're missing the point. The point is, when I have two dozen XS-based modules to install on multiple machines, especially of different architecture (Windows, Unix, Linux, Mac, mainframe) where each architecture comes with different levels of different supporting code (if it comes with it at all, e.g., Linux comes with expat, but AIX doesn't), that's a lot to pull together. Yes, it can be done. It's just a reasonable amount of effort to do.

    And then you get situations where you have to fight a beaurocracy to get it done on hundreds of machines that you don't otherwise even have access to, but they need something to use the perl software you wrote depending on it (directly or indirectly). Not that this is incredibly different if we were to be writing in C - depending on expat is depending on expat. However, there are way more people who understand C/C++ limitations and are willing to work with them than there are for perl - so it's just a struggle.

    And, of course, in C/C++, I find people are often less willing to reuse existing code, preferring to reinvent wheels. So then the issue doesn't come up as often.

[reply]

      I'm not missing the point: I just don't agree with yours. There's a difference.

      You have to install software on a bunch of different architectures, machines you don't have access to, and you have to fight a bureaucracy. I don't see how any of those problems are solved by anything we're talking about. You still have to install software on a bunch of different machines of different architectures and you still have to deal with the bureaucracy.

      I've been in that situation, and I always had CDs with all the binaries I needed. I compiled everything I needed and then I had it. Installing it on one machine or a hundred made no difference to me. Finding popular libraries is very easy, finding binaries of them is very easy, and in most cases compiling them is five minutes of work to get the thing going. After that, it doesn't matter if it's Perl or C or Java or anything else: you still have to push it to all the machines.

      I wouldn't keep around a sysadmin who couldn't do this easily, and I certainly wouldn't tolerate any whining about it being too much work when I know it's not. This is not the sort of problem that a good sysadmin seriously complains about.

      So, you have a tough job, and you know Perl. Let's see some code that solves it. Perl's all about making the hard things possible, so the people who keep complaining about hard things just aren't trying.

      --
      brian d foy <brian@stonehenge.com>
[reply]

        You mean, I should write code to do an Automated module install? Part one was "easy" (only took me about 10 hours so far to code and test on Linux, AIX, Windows). Part two, the part I was referring to above, is something I'm not even really sure where to start. Determining what the external dependancy is, programmatically, is not something I'm looking forward to. Figuring out dynamically that XML::Parser requires expat (and then automatically finding it), while figuring out that Crypt::SSL requires OpenSLL (and then automatically finding it), and any other module I may need to distribute ... that's not going to be fun.

        More likely is that I figure out my own dependancies by hand, then manually acquire the source/binaries, and then write code that handles that instead. It's not hard, it's just work.

        Note that dynamically figuring out that XML::Twig required XML::Parser was painful enough - I'm not sure I want to go through it again for the external libraries ;-) This was due to Makefile.PL-based modules and Build.PL-based modules wanting to do everything differently. And I didn't really want to start parsing perl - perl itself has a hard enough time doing that, and I'm not nearly smart enough to write code to do it. So I kick off the .PL script and parse the output (which is why I had to work out why opening '-|' on Windows wasn't working).

        I'm not linking to my old articles for people to vote on them. I'm linking to them to show that I'm already trotting down the proffered road and encountering issues which I really hoped I wouldn't.

[reply]
Re^4: Disputation of g0n on the power and efficacy of XS
by jhourcle (Prior) on Apr 21, 2005 at 12:35 UTC

    expat isn't a hard find, but it'd be possible that other modules may use more obscure programs, which may not be available as source, or may be outdated and not compile under the compiler suite that you have available.

    I wouldn't mind seeing better use of the DSLIP codes when searching CPAN, or for there to be a more consistent way for there to be checking in Makefile.PL to verify non-perl dependancies. Of course, it would be difficult to determine the versions of any non-perl requirements. (which I got stung on just last week -- Astro::FITS::CFITSIO requires cfitsio. I didn't think it a problem to install cfitsio through darwin ports. One of the tests failed for Astro::FITS::CFITSIO. After much frustration, I did a little searching, and stumbled across the main site for Astro::FITS::CFITSIO, which mentions:

    NOTE: version 2.500 of the cfitsio library is required.

    No where is this mentioned in the POD for Astro::FITS::CFITSIO. (and of course, darwin ports had an earlier version)

    expat is just the tip of the iceburg. Other modules may contain dependancies on Fortan, like cfitsio, or other languages, that might make it otherwise more complicated to install. It'd be nice for those modules that are just perl wrapped around another program, for there to be a way to find something that is a pure perl implementation, especially when you're trying to debug interaction issues. (eg, Mozilla::LDAP vs. Net::LDAP)

[reply]

In Section Meditations