Bug#501688: dh-make-perl ignoring build_requires in Makefile.PL

[Damyan Ivanov]

-=| Paul Fenwick, Sun, Nov 23, 2008 at 09:33:39PM +1100 |=-
> Damyan Ivanov wrote:
> > You may want to join forces with Paul Fenwick (cc-ed) who intented 
> > to do some incremental de-uglification. Paul, you mentioned a Git 
> > repository, any chance to get it published?
> 
> Done.  The repo can be found at:
> 
> 	http://github.com/pfenwick/dh-make-perl/tree/master
> 
> Files and changes can be browsed on that page, as well as instructions on
> cloning the repo should you wish to do so.  My changes are based on r26959
> from svn.  Commit access provided upon request; you'll need a (free) github
> account to make direct commits.

Oh. My apologies. You already mentioned that URL. Sorry for not paying 
enough attention.

> Presently all I've done is reformat dh-make-perl using perltidy and 
> the Perl
> Best Practices recommended tidyfile which can be found at
> http://www.perlmonks.org/?node_id=485885 .  Unless perltidy has booched, all
>  changes should be non-significant whitespace and comments only.

I'll review the two commits and merge them in out tree.

> However dh-make-perl has everything in one great big file, which 
> takes testing of subroutines hard. When we load dh-make-perl into 
> perl, it actually wants to run the application; for testing we want 
> to poke and prod individual subroutines and sections of code, and 
> make sure they work as they expect.  At the moment, unit testing for 
> dh-make-perl is hard.

I agree with you that breaking the present monolith approach into 
sub-modules each of which does one simple is good.

> We wrap the entire "main" program that usually runs when 
> dh-make-perl is
> invoked inside an actual "sub main { }", just like would in C.  We then have
> a tiny snippet of code that tests if $0 (our program name) is equal to
> __FILE__ (our filename).  If they're the same, we're running dh-make-perl as
> a program, and invoke it by calling our main subroutine.  If they're
> different, we're loading it as a module (probably for testing), and do nothing.

Oh, nice hack :)

> The big advantage here is that we can do actually do unit testing, but it
> should also highlight any areas of strong coupling in the code.  Since all
> the main code will be inside its own lexical scope, any variables that were
> previously "shared" between subroutines and the main program should be
> caught by strict, and the code can then be adjusted to pass these in
> explicitly.  This in turn makes the code easier to test and maintain.

ACK.

What bothers me more is the 'input' and 'output' of dh-make-perl. We 
don't test if a given function returns what is expected when given 
some arguments. We give a CPAN ('input') dist and then get a debian/ 
directory added to it with various files in ('output'). How could this 
be achieved if the only testing instruments we have are ok(), is_FOO() 
etc?

> What this means is that you shouldn't be waiting on me in the 
> short-term.  I really, truly want dh-make-perl to use META.yml more, 
> because it solves a huge number of my headaches, especially for 
> modules that I directly or indirectly maintain.  However I'm not 
> likely to feel those headaches again until after Christmas.

Well, we can implement the META.yml usage now (possibly adding to the 
ugliness) and deal with the rewrite in slower pace as the time 
permits.

But, a testing framework could be useful for both the current and the 
new, rewritten, code so if you know some tricks that do not rely on 
the codebase being modular and clean, please don't hold them for 
yourself :)

All I can think of is having severaal sample dists (t/Sample-ModuleX) 
and a coresponding debian directory (t/Sample-ModuleX-debian?), 
running dh-make-perl on the dist directories and comparing the 
resulting debian/ directory with the model.

-- 
dam            JabberID: dam at jabber.minus273.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20081123/f5ffb314/attachment-0001.pgp