Thread: [Module-build-general] Re: META.yaml in Module-Build dist
Status: Beta
Brought to you by:
kwilliams
From: Ken W. <ke...@ma...> - 2002-08-14 00:05:28
|
Hi Graham, You're right, I'll change the name to the distribution name. Regarding the version, it should be settable in the Build.PL if it doesn't come from a module, just like in MakeMaker. Is there something that needs fixing there? Perhaps the 'module_name', 'module_version', and 'module_version_from' parameters are misnamed in the new() method, since they (should) really refer to the distribution, not a module. Is this what you mean? Thanks for the suggestions. -Ken On Wednesday, August 14, 2002, at 12:44 AM, Graham Barr wrote: > Ken, > > I am looking forward to having a meta file in distributions so > that search can start using it. However I was reading the fail > in the Module-Build distribution. It contains the line > > name: Module::Build > > I would suggest that this is wrong. A distribution is not one module > and the meta file should be about the distribution. IMO that line > should be > > name: Module-Build > > consider distributions like libnet, libwww-perl or any other > distribution that contains many modules. > > The same goes for the version. In these distribution that > have many modules, the version of the distribution is > not always extracted from one of the modules. > > Graham. |
From: Graham B. <gb...@po...> - 2002-08-14 10:47:51
|
After sending this I started to compare with what MM does. With MM you pass NAME and VERSION or VERSION_FROM. Where NAME is a module name. You can optionally pass DISTNAME and DISTNAME defaults to NAME =~ s/::/-/g So maybe all that sneeded is for another method + yaml entry for distname. Also read your docs. The autosplit call. Why do you need it ? MM does a scan of each .pm for /^use AutoSplit/ to determine which need splitting. Graham. On Wed, Aug 14, 2002 at 10:30:26AM +1000, Ken Williams wrote: > Hi Graham, > > You're right, I'll change the name to the distribution name. > Regarding the version, it should be settable in the Build.PL if > it doesn't come from a module, just like in MakeMaker. Is there > something that needs fixing there? Perhaps the 'module_name', > 'module_version', and 'module_version_from' parameters are > misnamed in the new() method, since they (should) really refer > to the distribution, not a module. Is this what you mean? > > Thanks for the suggestions. > > -Ken > > On Wednesday, August 14, 2002, at 12:44 AM, Graham Barr wrote: > > > Ken, > > > > I am looking forward to having a meta file in distributions so > > that search can start using it. However I was reading the fail > > in the Module-Build distribution. It contains the line > > > > name: Module::Build > > > > I would suggest that this is wrong. A distribution is not one module > > and the meta file should be about the distribution. IMO that line > > should be > > > > name: Module-Build > > > > consider distributions like libnet, libwww-perl or any other > > distribution that contains many modules. > > > > The same goes for the version. In these distribution that > > have many modules, the version of the distribution is > > not always extracted from one of the modules. > > > > Graham. > |
From: Ken W. <ke...@ma...> - 2002-08-14 11:42:36
|
On Wednesday, August 14, 2002, at 08:43 PM, Graham Barr wrote: > After sending this I started to compare with what MM does. > > With MM you pass NAME and VERSION or VERSION_FROM. Where NAME > is a module name. You can optionally pass DISTNAME > > and DISTNAME defaults to NAME =~ s/::/-/g > > So maybe all that sneeded is for another method + yaml entry > for distname. Yeah, that's close to what I'm thinking. Here's my current proposal: 1) Replace module_version and module_version_from parameters with dist_version and dist_version_from. They really were facts about the distribution anyway, but I didn't realize it. 2) Create a dist_name parameter which is essentially the same as MakeMaker's NAME parameter. 3) Make module_name into a shortcut for setting dist_name and dist_version_from in one go. This handles the most common case nicely, in which a distribution houses a single "chief" module. I don't think I have a problem with the backward-compatibility breakage of 1). 2) and 3) don't have any such problems. > Also read your docs. The autosplit call. Why do you need it ? > MM does a scan of each .pm for /^use AutoSplit/ to determine > which need splitting. I can't actually find that in the MM source, can you point me to it? I know it was happening *somehow* automatically, though. Part of the reason I changed it was that I didn't like the magical scanning of code in MM. I think the scanning for $VERSION is unfortunately quite necessary, but I'd like for that to be the only code scanning if possible. -Ken |
From: Graham B. <gb...@po...> - 2002-08-14 11:59:09
|
On Wed, Aug 14, 2002 at 09:43:10PM +1000, Ken Williams wrote: > > Also read your docs. The autosplit call. Why do you need it ? > > MM does a scan of each .pm for /^use AutoSplit/ to determine > > which need splitting. > > I can't actually find that in the MM source, can you point me to it? > > I know it was happening *somehow* automatically, though. Part > of the reason I changed it was that I didn't like the magical > scanning of code in MM. I think the scanning for $VERSION is > unfortunately quite necessary, but I'd like for that to be the > only code scanning if possible. Actually it does not look for use AutoSplit. ExtUtils::Install calls autosplit() on _every_ .pm file as it installs it into blib. autosplit() will check for use AutoLoader Graham. |