Thread: [Module-build-general] Question about Defaults ...
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Norbert G. <no...@MP...> - 2003-03-14 10:44:44
|
Dear Module::Build designers, recently I have read the article on Perl.com about your module Module::Build. I was very fascinated by your idea to handle the complete installation procedure of modules under the control of Perl. This is a very fine module, well done :-)) Since I think this is a very good approach, I started to look into your module if I could convert to your way of installing. Unfortunately I found out that you are expecting all module files (.pm or .xs) sitting in the directory "lib/". But this directory structure is not the default structure when you are starting your development by using "h2xs". My question is, what is the reason for this requirement ? And is there a possibility to switch off this behavior ? Of course, I know how to accomplish your requirement :-). But this would mean that I have to fiddle about the directory structure after running the initial h2xs. Cheers, Norbert -- Ceterum censeo | PGP encrypted mail preferred. Redmond esse delendam. | PGP Key at www.MPA-Garching.MPG.de/~nog/ |
|
From: Dave R. <au...@ur...> - 2003-03-14 18:46:46
|
On Fri, 14 Mar 2003, Norbert Gruener wrote: > Since I think this is a very good approach, I started to look into > your module if I could convert to your way of installing. > Unfortunately I found out that you are expecting all module files (.pm > or .xs) sitting in the directory "lib/". But this directory structure > is not the default structure when you are starting your development by > using "h2xs". h2xs for module creation needs to die along with MakeMaker ;) > My question is, what is the reason for this requirement ? And is > there a possibility to switch off this behavior ? Of course, I know > how to accomplish your requirement :-). But this would mean that I > have to fiddle about the directory structure after running the initial > h2xs. I think Ken did this cause it's easy ;) Seriously, I'm sure he'd welcome support for alternate layouts. By default, I think it should look in lib/ and then the current directory for .pm and .pod files. With MakeMaker, there's also a way to map a different layout to the installation layout, using the PM option. I'm not sure this is really worthwhile, though. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-03-14 22:21:23
|
On Friday, March 14, 2003, at 12:45 PM, Dave Rolsky wrote: > On Fri, 14 Mar 2003, Norbert Gruener wrote: > >> My question is, what is the reason for this requirement ? And is >> there a possibility to switch off this behavior ? Of course, I know >> how to accomplish your requirement :-). But this would mean that I >> have to fiddle about the directory structure after running the initial >> h2xs. > > I think Ken did this cause it's easy ;) Yeah, that was a big part of it. I've had to convert several of my own projects to this layout too, so I know it's a (little) hassle. I've had people tell me that it was a good decision though, so I'd like to hear more arguments on either side. I think that using just lib/ makes things easier not just for me, but for people who are trying to figure out how modules put themselves together during the build process. But I'm sympathetic to the migration issues too. > Seriously, I'm sure he'd welcome support for alternate layouts. By > default, I think it should look in lib/ and then the current directory > for > .pm and .pod files. With MakeMaker, there's also a way to map a > different > layout to the installation layout, using the PM option. I'm not sure > this > is really worthwhile, though. There are other issues to consider too. Right now MakeMaker looks for subdirectories containing Makefile.PLs and builds stuff recursively in these directories. This is actually the only way you can have more than one .xs file in a distribution using MakeMaker. M::B doesn't do recursive subdirectories at this point either. It's not usually a problem because M::B will compile .xs files inside lib/ , which MakeMaker won't do. If we add the ability to have sub-builds in subdirectories, I'm probably going to insist that these subdirectories are explicitly listed in the Build.PL, rather than auto-detected. I've never cared for the auto-detect stuff in MakeMaker, and it was a big reason why I wanted Every Installable Thing In Lib/ (sic). -Ken |
|
From: Iain 'S. T. <tmd...@de...> - 2003-03-20 05:13:57
|
* Ken Williams (ke...@ma...) [15 Mar 2003 09:24]: [...] > If we add the ability to have sub-builds in subdirectories, I'm > probably going to insist that these subdirectories are explicitly > listed in the Build.PL, rather than auto-detected. I've never cared > for the auto-detect stuff in MakeMaker, and it was a big reason why I > wanted Every Installable Thing In Lib/ (sic). I do actually use the recursive stuff. It's very useful for packaging modules together in a single lump. I have a bunch of in-house modules that generally get installed in one go and it's usual to just extract them all into the one directory and have a more or less empty Makefile.PL in the top level. A quick "perl Makefile.PL && make test install" later and they're all done. I'd be irritated if I had to explicitly list each one. On the XS front, is there a reason why compiles are done in lib rather _build or somewhere like that? I realise the objects get picked up by 'clean' anyway, and EU::MM was never that tidy about this, but the interim build state of a module might as well be tidy. No biggie though. cheers, --=20 Iain. |
|
From: Ken W. <ke...@ma...> - 2003-03-20 14:06:06
|
On Wednesday, March 19, 2003, at 11:13 PM, Iain 'Spoon' Truskett wrote: > > I do actually use the recursive stuff. It's very useful for packaging > modules together in a single lump. > > I have a bunch of in-house modules that generally get installed in one > go and it's usual to just extract them all into the one directory and > have a more or less empty Makefile.PL in the top level. A quick "perl > Makefile.PL && make test install" later and they're all done. > > I'd be irritated if I had to explicitly list each one. Hmm. Okay. We'll see if we can find some way to support both ways. Maybe even just a "recursive_build => 1" flag or something. > On the XS front, is there a reason why compiles are done in lib rather > _build or somewhere like that? I realise the objects get picked up by > 'clean' anyway, and EU::MM was never that tidy about this, but the > interim build state of a module might as well be tidy. No biggie > though. Yeah, they should be done in some subdirectory of _build/ . This has been on my unofficial to-do list (maybe I should use RT for this instead of my subconscious) for a while now. -Ken |
|
From: Nicholas C. <ni...@un...> - 2003-03-14 23:37:05
|
On Fri, Mar 14, 2003 at 12:45:17PM -0600, Dave Rolsky wrote: > h2xs for module creation needs to die along with MakeMaker ;) and xsubpp (being worked on, IIRC) etc h2xs isn't going to die in 5.8.1 But I suspect that there's still time to get a patch for 5.8.1 in to add an option to h2xs to make the module use Module::Build rather than MakeMaker Nicholas Clark |
|
From: Randy W. S. <Ra...@Th...> - 2003-03-15 12:33:35
|
On 3/14/2003 6:09 PM, Nicholas Clark wrote:
> On Fri, Mar 14, 2003 at 12:45:17PM -0600, Dave Rolsky wrote:
>
>>h2xs for module creation needs to die along with MakeMaker ;)
>
>
> and xsubpp (being worked on, IIRC) etc
>
> h2xs isn't going to die in 5.8.1
> But I suspect that there's still time to get a patch for 5.8.1 in to add an
> option to h2xs to make the module use Module::Build rather than MakeMaker
>
> Nicholas Clark
>
This brings to mind a problem I've run into: What about CPAN authors who
want to provide both Makefile.PL and Build.PL during the transition for
backwards compatibility? When I try this Makefile.PL wants execute
Build.PL as a self-extracting script. Maybe this has come up before, but
I couldn't find any references.
Two options that immediately come to mind are:
* Require that the PL_FILES option be specified in the Makefile.PL even
if it is an empty array so that MM doesn't perform its auto search for
PL files.
* Add something like the following to the top Build.PL:
BEGIN { # Don't let it MakeMaker extract me && substitute my variables.
exit if @ARGV == 1 && $ARGV[0] eq 'Build';
}
What is the best way to handle this scenario? I'm currently using the
second. Although its a hack, it feels like a better solution than
requiring authors to change their existing Makefile.PL to explicitly
mention every PL file.
Randy.
--
A little learning is a dang'rous thing;
Drink deep, or taste not the Pierian spring;
There shallow draughts intoxicate the brain;
And drinking largely sobers us again.
- Alexander Pope
|
|
From: Dave R. <au...@ur...> - 2003-03-15 20:09:53
|
On Sat, 15 Mar 2003, Randy W. Sims wrote:
> This brings to mind a problem I've run into: What about CPAN authors who
> want to provide both Makefile.PL and Build.PL during the transition for
> backwards compatibility? When I try this Makefile.PL wants execute
> Build.PL as a self-extracting script. Maybe this has come up before, but
> I couldn't find any references.
>
> Two options that immediately come to mind are:
>
> * Require that the PL_FILES option be specified in the Makefile.PL even
> if it is an empty array so that MM doesn't perform its auto search for
> PL files.
>
> * Add something like the following to the top Build.PL:
> BEGIN { # Don't let it MakeMaker extract me && substitute my variables.
> exit if @ARGV == 1 && $ARGV[0] eq 'Build';
> }
>
> What is the best way to handle this scenario? I'm currently using the
> second. Although its a hack, it feels like a better solution than
> requiring authors to change their existing Makefile.PL to explicitly
> mention every PL file.
Have you looked at the docs for Module::Build::Compat? It has an example
Makefile.PL that simply passes through everything to Build.PL, and it even
can install Module::Build for you if it's not already installed. I've
used it with at least one module on CPAN, Thesaurus, and it works quite
well.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
|
|
From: Randy W. S. <Ra...@Th...> - 2003-03-16 15:06:56
|
On 3/15/2003 3:08 PM, Dave Rolsky wrote:
> On Sat, 15 Mar 2003, Randy W. Sims wrote:
>
>
>>This brings to mind a problem I've run into: What about CPAN authors who
>>want to provide both Makefile.PL and Build.PL during the transition for
>>backwards compatibility? When I try this Makefile.PL wants execute
>>Build.PL as a self-extracting script. Maybe this has come up before, but
>>I couldn't find any references.
>>
>>Two options that immediately come to mind are:
>>
>>* Require that the PL_FILES option be specified in the Makefile.PL even
>>if it is an empty array so that MM doesn't perform its auto search for
>>PL files.
>>
>>* Add something like the following to the top Build.PL:
>>BEGIN { # Don't let it MakeMaker extract me && substitute my variables.
>> exit if @ARGV == 1 && $ARGV[0] eq 'Build';
>>}
>>
>>What is the best way to handle this scenario? I'm currently using the
>>second. Although its a hack, it feels like a better solution than
>>requiring authors to change their existing Makefile.PL to explicitly
>>mention every PL file.
>
>
> Have you looked at the docs for Module::Build::Compat? It has an example
> Makefile.PL that simply passes through everything to Build.PL, and it even
> can install Module::Build for you if it's not already installed. I've
> used it with at least one module on CPAN, Thesaurus, and it works quite
> well.
>
>
> -dave
Yea. I'd seen the info on the Compat module, and it suits me fine for my
purposes. I guess what I was concerned about were the users out there
with older versions of perl where upgrading is either not possible or a
slow process. They might not be able to use M::B (unless it's
backported). Also, many CPAN authors may be reluctant to simply throw
out their tried and trusted Makefile.PLs in favor a still relatively
young M::B. (I'm not saying M::B isn't solid; It's just that people
often perceive something new as being more "risky" than something
known.) It would seem to make the transition easier if the two could
coexist.
M::B is definately a better and more extensible tool for building
modules, and I look forward to its displacement of MM ;). I just wanted
to point out the potential conflict since I didn't know if it had been
previously discussed.
Randy.
--
A little learning is a dang'rous thing;
Drink deep, or taste not the Pierian spring;
There shallow draughts intoxicate the brain;
And drinking largely sobers us again.
- Alexander Pope
|
|
From: Michael G S. <sc...@po...> - 2003-03-19 20:09:19
|
On Fri, Mar 14, 2003 at 12:45:17PM -0600, Dave Rolsky wrote: > > Since I think this is a very good approach, I started to look into > > your module if I could convert to your way of installing. > > Unfortunately I found out that you are expecting all module files (.pm > > or .xs) sitting in the directory "lib/". But this directory structure > > is not the default structure when you are starting your development by > > using "h2xs". > > h2xs for module creation needs to die along with MakeMaker ;) Seconded. > > My question is, what is the reason for this requirement ? And is > > there a possibility to switch off this behavior ? Of course, I know > > how to accomplish your requirement :-). But this would mean that I > > have to fiddle about the directory structure after running the initial > > h2xs. > > I think Ken did this cause it's easy ;) For my $0.02, I've always felt all the alternative layout options in MakeMaker (I think there's three) are just unnecessarily confusing and complicated. I don't think Module::Build should bother. It might want to include some way to customize the behavior, probably via overriding the "find my modules" methods which are currently hard-coded in ACTION_build and ACTION_manifypods. That feels cleanest and actively improves the structure of M::B. -- A Significant Benefit To Canada |
|
From: Ken W. <ke...@ma...> - 2003-03-20 14:03:36
|
On Wednesday, March 19, 2003, at 02:06 PM, Michael G Schwern wrote: > > For my $0.02, I've always felt all the alternative layout options in > MakeMaker (I think there's three) are just unnecessarily confusing and > complicated. I don't think Module::Build should bother. > > It might want to include some way to customize the behavior, probably > via > overriding the "find my modules" methods which are currently hard-coded > in ACTION_build and ACTION_manifypods. That feels cleanest and > actively > improves the structure of M::B. Sounds good to me. -Ken |
Thanks for helping keep SourceForge clean.
X