Skip Menu |

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 34457
Status: open
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: schwern [...] pobox.com
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: Rerunning Build.PL does not rebuild
Date: Wed, 26 Mar 2008 14:14:06 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Rerunning the Build.PL should cause everything to be rebuilt, because who knows what changed? It does not. The attached tarball demonstrates the problem. $ cd MB-Test $ perl Build.PL Checking prerequisites... Looks good Creating new 'Build' script for 'MB-Test' version '0.01' $ ./Build Copying lib/MB/Test.pm -> blib/lib/MB/Test.pm Manifying blib/lib/MB/Test.pm -> blib/libdoc/MB::Test.3 $ perl Build.PL Checking prerequisites... Looks good Deleting Build Removed previous script 'Build' Creating new 'Build' script for 'MB-Test' version '0.01' $ ./Build -- 100. Claymore mines are not filled with yummy candy, and it is wrong to tell new soldiers that they are. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Download MB-Test.tgz
application/x-gzip 423b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #34457] Rerunning Build.PL does not rebuild
Date: Wed, 26 Mar 2008 16:44:44 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <scratchcomputing [...] gmail.com>
# from Michael G Schwern via RT # on Wednesday 26 March 2008 14:14: Show quoted text
>Rerunning the Build.PL should cause everything to be rebuilt, because > who knows what changed?  It does not.
Should "./Build" be implicitly checked by up_to_date()? If so, then what about your subclass .pm files? What about code that they use? That can make slow operations really frustrating when dealing with custom subclasses. I have other nits about up_to_date(), but it is very DWIM and it seems like changing the behavior creates a lot of possibility for breakage or unwanted effects. --Eric
Subject: Re: [rt.cpan.org #34457] Rerunning Build.PL does not rebuild
Date: Wed, 26 Mar 2008 17:39:50 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Eric Wilhelm via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=34457 > > > # from Michael G Schwern via RT > # on Wednesday 26 March 2008 14:14: >
>> Rerunning the Build.PL should cause everything to be rebuilt, because >> who knows what changed? It does not.
> > Should "./Build" be implicitly checked by up_to_date()?
An up-to-date check on Build.PL => Build should probably just be added to ACTION_build, which is analogous to how MakeMaker puts the Makefile as a dependency on its all target. Unfortunately, Module::Build doesn't seem to have a way to cascade like make does. ACTION_code() doesn't say "oh, ACTION_build() changed so I'll rebuild all the dependencies" because that's governed by it's own local up_to_date() checks. What might make sense is to add in a local object flag which tells up_to_date() to always fail. When an action decides its changed it can set the flag using local which informs its dependent actions to rebuild. Show quoted text
> If so, then what about your subclass .pm files? What about code that they use? > That can make slow operations really frustrating when dealing with > custom subclasses.
This is more an issue to come up for a subset of authors, so it doesn't have as broad an impact on users. It's hairy and I'm happy to just split it out into another ticket. Maybe subclass() can do something intelligent for those who like that interface. Or maybe we just need a simple way to allow users to add file dependencies to actions. -- ...they shared one last kiss that left a bitter yet sweet taste in her mouth--kind of like throwing up after eating a junior mint. -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest by Tami Farmer