Dear David,
I visited your site and found the perl-dep program
you wrote to "Find dependencies in perl code",
e.g. see http://www.cantrell.org.uk/david/tech/perl-dep/
What is the status of this?
I am curious why you did not explicitly mention this tool
in this thread on code maintenance.
I'd like to come down from the ivory tower (CMM etc.)
and talk about software engineering with perl.
The biggest problem I have with maintaining Perl code
is a result of the fact that I am running on Windows.
Module writers that include *.c files that must be compiled
cause me great headaches. Most recent example
is HTML::Parser, which failed to link because it
could not find the file msvcrt.lib, which it thought
it needed because it was named in config.pm, which
was the config.pm that came from ActiveState.
I have not solved this problem and wouldn't mind
useful advice. Among the possibilities:
1. Discover which file that I do have that can be used
instead (perhaps msvcrtd.lib ?) and then figure
out to change config.pm
2. Download gcc and recompile everything,
including perl itself. (I may try this when 5.8 is stable.)
3. Download entire ActiveState and hope that HTML::Parser
is include dby default, and that ActiveSTate doen't trash
what I already have running
These are variants of the general big problem
of how to overlay a new version of code (e.g. a module)
over an older version.
It still is not clear to me how to get a reliable CPAN
module (I read somewhere that a new versions fixes
various bugs). I have also hit serious problems
with XML::Parser, (some kind of circular dependency
on itself perhaps.)
Perl is terrible about making things easy yo install.
Getting the useful sitemanager.pl propram to work
required many separate download, e.g.
WWW::Sitemap, WWW::Robot, HTML::Parser, etc, etc.
In theory there is now some package manager - but
this does not help with older code.
When 5.8 ships I will really need a solution to these
issues. I do NOT want to start from scratch.
I believe the new philosophy is to ship with fewer
modules in the core. I would actually prefer the
opposite approach -- give me everything that
seems to work. Disks are really big these days and
code is small.
Again, concrete advice would be appreciated.
Hopefully helpfully yours,
Steve
--
Steven Tolkin [EMAIL PROTECTED] 617-563-0516
Fidelity Investments 82 Devonshire St. V8D Boston MA 02109
There is nothing so practical as a good theory. Comments are by me,
not Fidelity Investments, its subsidiaries or affiliates.
> -----Original Message-----
> From: David Cantrell [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 13, 2002 8:51 AM
> To: Joe Johnston
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Boston.pm] maintenance of large perl code bases
>
>
> On Wed, Mar 13, 2002 at 07:46:46AM -0500, Joe Johnston wrote:
>
> > I've been very interested in software engineering practices
> for a while
> > now.
> >
> > ...
> >
> > Sure, programming is an art, but so is brige-building and highway
> > construction. Yet, the process that creates these real-world
> > constructs is very carefully controlled and monitored. Software
> > Engineer is lagging behind its physical counterparts.
>
> No, we're not lagging behind. Software engineering is VERY young - at
> most, 60 years old. Civil and naval engineering are more like four
> thousand years old and mechanical engineering at least two
> thousand years
> old. It is no surprise that they have managed to iron out a
> great deal
> more bugs in their processes than we have. And no, I don't
> think all our
> bugs are ones which have been solved in other engineering disciplines.
>
> --
> David Cantrell | Benevolent Dictator |
> http://www.cantrell.org.uk/david
>
> o/~ I want my SMTP o/~
>
