On Tue, Mar 29, 2005 at 04:43:30PM -0600, Ken Williams wrote: > I think there's one really good argument in favor of splitting it out > and one really good argument against. > > In favor: if we knew the subset of build_requires that were actually > needed for testing, then it would be easier for people to squirrel away > the regression tests and run them again after the module is installed. > I think people have been vaguely wanting that for a long time. > > Against: in the perl culture (largely because of the way MakeMaker has > always been implemented), testing has always been seen as an integral > part of the build process. By having people declare testing > dependencies as part of build_requires, we reinforce this notion. > > On the whole, though, I think it's probably a good idea.
To throw weight onto the "in favor" side. MB is a build tool. Tools should be flexible. Which choice results in the most flexible tool? Tools should also avoid trying to push their philosophy on others. It reduces flexibility and often chafes. Give the user the information and let them decide. Push your philosophy through the defaults, not by withholding information. > On a related note, we should probably finally make the > prerequisite-specification system treat the requirement level (requires > vs. recommends vs. conflicts) and requirement scope (build vs. test vs. > runtime) as completely orthogonal. Currently there's no such thing as > build_recommends, for instance, but there's really no good reason it's > missing. I'd agree here, too. If nothing else so that the user can decide if they really want that enormous optional module or if its just something that's going to allow one test to run.
