module-build-general — General discussion about Module::Build project

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[Ken W. <ke...@ma...>]

On Feb 16, 2006, at 11:46 AM, John Peacock wrote:

> Is there some overriding reason you are avoiding upgrading the YAML 
> prereq to 0.50 (which in itself isn't even the current rev)?

Good question.  I guess not, though this is the first time I think we'd 
upgrade an auto-feature dependency, and it has just occurred to me that 
it'll catch people by surprise if they currently have that feature 
enabled.  It will suddenly get non-enabled without much warning.

  -Ken

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

[Ken W. <ke...@ma...>]

On Feb 16, 2006, at 11:45 AM, Tyler MacDonald wrote:

> 	I think "passthrough" is the way to go here. I also still think that
> if we default in some way to generating a Makefile.PL, 
> create_makefile_pl
> should be extended to have an explicit "skip" option as well.

Definitely.  I'd just change the default to 'auto' (which means create 
a 'small' [or 'passthrough'] Makefile.PL if none already exists) 
though, and then the author can explicitly put "create_makefile_pl => 
0" (or any other false value) in their Build.PL to shut it off.

If in the future we figure out how to auto-sense when we could create a 
'traditional' Makefile.PL that would be cool, but I don't really see it 
happening.  Too hard.

  -Ken

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[David W. <da...@ki...>]

On Feb 16, 2006, at 09:49, Ken Williams wrote:

> I don't have such a link, but essentially any info sent to STDERR/ 
> STDOUT during testing is lost because CPANPLUS calls the 'test'  
> action through the M::B API, not in a subprocess like it does for  
> EU::MM, and doesn't capture those filehandle outputs.

Oh. That should be easy to fix with a tied or piped file handle.  
Test::Output has the code that's needed.

Best,

David

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[Ken W. <ke...@ma...>]

On Feb 16, 2006, at 11:38 AM, David Wheeler wrote:

> On Feb 16, 2006, at 09:27, Ken Williams wrote:
>
>> That's good.  The specific bug I know (knew?) about was that 
>> cpan-testers error reports don't include any diagnostic output when 
>> they're generated by CPANPLUS using a Build.PL - so I guess either 
>> it's fixed, or your modules never generate errors. =)
>
> Someone told me about this bug after cpanp sent them a failure report 
> from my Mac. But what "diagnostic" information is missing, exactly? 
> Maybe there are some links to what it looks like and what it should 
> look like in the cpan-testers archives?

I don't have such a link, but essentially any info sent to 
STDERR/STDOUT during testing is lost because CPANPLUS calls the 'test' 
action through the M::B API, not in a subprocess like it does for 
EU::MM, and doesn't capture those filehandle outputs.

  -Ken

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[John P. <jpe...@ro...>]

Ken Williams wrote:
> 
> On Feb 15, 2006, at 4:06 PM, John Peacock wrote:
>> Never mind.  Upgrading YAML to current (0.58) works much better and 
>> setting $YAML::Stringify does exactly what we want.
> 
> Is there no way to support YAML 0.35?  That's our current YAML 
> prerequisite.

Nope.  Once you throw an object into the mix, YAML gets very confused. 
Apply my patch and try it with 0.35 and you will see:

1) a screenful of warnings thrown during the META.yml creation;
2) worse yet, the META.yml is malformed (it doesn't include either a 
dump of the version object as hash nor the correct stringified 
representation).

I can, with some more difficulty, patch M::B to force a stringification 
of version objects prior to inserting them into the $node, but it isn't 
nearly as clean.

Is there some overriding reason you are avoiding upgrading the YAML 
prereq to 0.50 (which in itself isn't even the current rev)?

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

[Tyler M. <ty...@yi...>]

Ken Williams <ke...@ma...> wrote:
> >*build* directory already... as far as I understand, our Makefile.PL only
> >needs to be generated in the *dist* directory.
> 
> Yeah, that's true.
> 
> Let me reconsider my reasoning here from scratch.  The original point 
> that Adam & Yves were making, IIUIC, was that distributions should 
> include a Makefile.PL.  If they don't have one at all, then of course 
> we don't need to worry about clobbering one!  So I'd be fine with 
> changing the default in this case to provide some flavor of Makefile.PL 
> generated in the dist directory.
> 
> The main question would be what style to make it.  'traditional' is 
> accessible by more people, but will often be broken (if, e.g., there 
> are config questions or auto-sensing in the Build.PL they'll be lost to 
> the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' 
> for this case.

	I think "passthrough" is the way to go here. I also still think that
if we default in some way to generating a Makefile.PL, create_makefile_pl
should be extended to have an explicit "skip" option as well.

> That should make most people happy, no?

	Sounds good to me. :-)

		- Tyler

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

[Ken W. <ke...@ma...>]

On Feb 14, 2006, at 1:16 PM, Tyler MacDonald wrote:

> Ken Williams <ke...@ma...> wrote:
>> If we did that, we'd screw over people who are already maintaining
>> their Makefile.PL separately by hand.
>
> 	OK... but if they are doing that, the Makefile.PL will be in their
> *build* directory already... as far as I understand, our Makefile.PL 
> only
> needs to be generated in the *dist* directory.

Yeah, that's true.

Let me reconsider my reasoning here from scratch.  The original point 
that Adam & Yves were making, IIUIC, was that distributions should 
include a Makefile.PL.  If they don't have one at all, then of course 
we don't need to worry about clobbering one!  So I'd be fine with 
changing the default in this case to provide some flavor of Makefile.PL 
generated in the dist directory.

The main question would be what style to make it.  'traditional' is 
accessible by more people, but will often be broken (if, e.g., there 
are config questions or auto-sensing in the Build.PL they'll be lost to 
the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' 
for this case.

That should make most people happy, no?

  -Ken

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[David W. <da...@ki...>]

On Feb 16, 2006, at 09:27, Ken Williams wrote:

> That's good.  The specific bug I know (knew?) about was that cpan- 
> testers error reports don't include any diagnostic output when  
> they're generated by CPANPLUS using a Build.PL - so I guess either  
> it's fixed, or your modules never generate errors. =)

Someone told me about this bug after cpanp sent them a failure report  
from my Mac. But what "diagnostic" information is missing, exactly?  
Maybe there are some links to what it looks like and what it should  
look like in the cpan-testers archives?

Best,

David

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[Chris D. <ch...@cl...>]

On Feb 16, 2006, at 11:27 AM, Ken Williams wrote:

> That's good.  The specific bug I know (knew?) about was that cpan- 
> testers error reports don't include any diagnostic output when  
> they're generated by CPANPLUS using a Build.PL - so I guess either  
> it's fixed, or your modules never generate errors. =)

/me takes a bow   :-)

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[Ken W. <ke...@ma...>]

On Feb 16, 2006, at 11:18 AM, Chris Dolan wrote:

> On Feb 16, 2006, at 10:01 AM, Ken Williams wrote:
>
>> I think it's been decided that we're not going to fix this for 0.28 
>> then.
>>
>> Of course, there's surely a CPANLUS equivalent of Yves out there 
>> somewhere who's going to say "M::B has its priorities wrong because 
>> they STILL don't support CPANPLUS!"  But this project has made my 
>> skin a bit thicker than it used to be, so those people can wait 
>> patiently or impatiently; the squeaky wheel will get the grease, 
>> CPANPLUS hasn't had any squeaky wheel people for a while now.
>
> Fair enough.  I'm happy as long as the decision isn't just because 
> "nobody we know uses CP+".  I also haven't seen any MB<-->CP+ breakage 
> myself in a long time.

That's good.  The specific bug I know (knew?) about was that 
cpan-testers error reports don't include any diagnostic output when 
they're generated by CPANPLUS using a Build.PL - so I guess either it's 
fixed, or your modules never generate errors. =)

  -Ken

[Module::Build] order of extra_compile_flags in compile_c

[R. B. <ro...@pa...>]

I recently used Module::Build in my first CPAN project
(Device:Cdio). This is a OO Perl wrapper for my libcdio library and I
used SWIG to help me. (See ticket 17666 on rt.cpan.org; and many
thanksfor considering as an inclusion this after the next M:B
release.)

One thing that came up in this endeavor was the order or the C flags
in the compilation (compile_c).  It is helpful to turn off some gcc
warning messages until such time SWIG is fixed to not cause gcc to
emit them. So I changed the order of applying user cflags
(extra_compiler_flags) to come *after* the cflags that are picked up
as part of the Perl configuration (via Config). Another possibility is
to add a new option to allow cflags specified before *and* afterwards.

(If this is something I should add a ticket for in rt.cpan.org, let me
know.)

Thanks.

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[Chris D. <ch...@cl...>]

On Feb 16, 2006, at 10:01 AM, Ken Williams wrote:

> I think it's been decided that we're not going to fix this for 0.28  
> then.
>
> Of course, there's surely a CPANLUS equivalent of Yves out there  
> somewhere who's going to say "M::B has its priorities wrong because  
> they STILL don't support CPANPLUS!"  But this project has made my  
> skin a bit thicker than it used to be, so those people can wait  
> patiently or impatiently; the squeaky wheel will get the grease,  
> CPANPLUS hasn't had any squeaky wheel people for a while now.

Fair enough.  I'm happy as long as the decision isn't just because  
"nobody we know uses CP+".  I also haven't seen any MB<-->CP+  
breakage myself in a long time.

Thanks Ken.
Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[Ken W. <ke...@ma...>]

On Feb 15, 2006, at 2:30 PM, Chris Dolan wrote:

> On Feb 15, 2006, at 2:17 PM, demerphq wrote:
>
>> On 2/15/06, Chris Dolan <ch...@cl...> wrote:
>>> On Feb 15, 2006, at 1:00 PM, Rob Kinyon wrote:
>>>
>>>> I may just be echoing commonly-held sentiment, but if 0.28 is being
>>>> held up because there's a bug in CPANPLUS, that's annoying. Neither 
>>>> I
>>>> nor anyone I know even uses CPANPLUS.
>>>
>>> Neither I nor anyone I know even uses Solaris.  Nonetheless, I would
>>> not recommend shipping 0.28 if it were broken under Solaris
>>> (hypothetically speaking).
>>>
>>> Just another CPANPLUS user,
>>
>> So then why dont you help the MB folks sort out this problem?
>>
>> Yves
>
> The key word is "user".  I've contributed bug fixes to both M::B and 
> CP+ in the past, but I simply don't understand the M::B <-> CP+ 
> interaction well enough to fix it myself.

I think it's been decided that we're not going to fix this for 0.28 
then.

Of course, there's surely a CPANLUS equivalent of Yves out there 
somewhere who's going to say "M::B has its priorities wrong because 
they STILL don't support CPANPLUS!"  But this project has made my skin 
a bit thicker than it used to be, so those people can wait patiently or 
impatiently; the squeaky wheel will get the grease, CPANPLUS hasn't had 
any squeaky wheel people for a while now.

  -Ken

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[Ken W. <ke...@ma...>]

On Feb 15, 2006, at 4:06 PM, John Peacock wrote:

> John Peacock wrote:
>> Dear Perl YAML-heads:
>> I've been trying to integrate version objects into Module::Build (now 
>> that I have a pure Perl release) and everything works except that 
>> YAML emits lots of warnings when trying to dump version objects:
>
> Never mind.  Upgrading YAML to current (0.58) works much better and 
> setting $YAML::Stringify does exactly what we want.

Is there no way to support YAML 0.35?  That's our current YAML 
prerequisite.

  -Ken

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[Ken W. <ke...@ma...>]

On Feb 15, 2006, at 4:29 AM, demerphq wrote:

> On 2/14/06, Ken Williams <ke...@ma...> wrote:
>> Randy just wrote me a message saying similar, so I think we should 
>> just
>> do the 0.28 release now.  We can make the version.pm and Build.bat
>> changes right away afterwards, or if we get some patches in the next
>> day or two I can put them in beforehand.
>
> I though i did provide a patch for the Build.bat issue.

Yes, it's been applied now but I'll need some help making sure it's 
correct because I couldn't apply it cleanly.  Once we confirm that and 
get version.pm stuff working (so that core isn't broken) and get some 
testing reports back (which probably means another beta) we can release 
0.28.  But no other features besides those.

  -Ken

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMakerin5.8.8 for UINST=1

[Rob K. <rob...@gm...>]

On 2/16/06, demerphq <dem...@gm...> wrote:
> Yes i agree.  In my view this has been the main misunderstanding of
> the MB project. The folks involved were very focued on author related
> concerns to the detriment of user related concerns. And typically when
> MB was criticised someone would come out of the woodwork and tell us
> how happy we should be as MB was much easier to extend and that we
> should just get used to MB because it was the future. (We even saw
> something along those lines in this thread.)

This points out a very big and well-known difference between the
author and user communities. More below.

> I mostly write this because I think that there are lessons to be
> learned from this. MB is a good idea, everybody who has had to fight
> with EUMM knows that. But the project made some signifigant mistakes
> that should be noted and learned from.

I think the biggest lesson is that the toolset(s) used by the author
to build and package the distro shouldn't be the same toolset(s) used
by the user to install the distro. Oh, the author's Build.PL (or
whatever) should be available for those 1% of uesrs who are actually
interested in extending a distro. But, it shouldn't be what the user
HAS to use.

This has come up in several incarnations on the MB list in the few
months I've been lurking. Most recently, there was the discussion on
author tests vs. installation tests. This past week, I've been trying
to figure out if it's worth my time to create an Author.PL that I use
when building which creates and uses a subclass of MB and provide a
Build.PL that uses the "stock" MB. In discussions with other CPAN
authors, the sentiment has been near-complete agreement with the need
for such a distinction. And, I think this ties in with the move to
split out the functionality in EUMM into manageable pieces that can be
depended upon separately.

As for Win32 ... what's wrong with having something that creates a
.msi? There are free (as in beer) installer makers that will create a
full installer. Need some modules? Put them in there! Need Perl? Put
it in there! Let the installer figure out what's needed for
installation (and where to put it!) and what's not.

As for requiring "C:\perl", that's a whole lot of people not
understanding how to make Win32 work for them. I don't know what the
solution is as I'm not a Win32 expert, but I know it has to be there
because Win32 is that easy for the user to use and for the developer
to develop to. The plethora of shareware points to the fact that there
are tools we as a community are not using. And, we should be.
Supposedly, the Perl community is one of the premiere hacker
communities. We can't ALL be Win32-clueless.

In short, I think we need to do the following:
1) Create a harder separation between the installer functionality and
the builder functionality. I would LOVE to see a Module::Build::Author
and a separate Author.PL become a community standard.
2) The Win32-capable among us should be providing some direction as to
the tools we're not using. If you know a shareware author, find out
what they used to build and package their product for installation.
Italian teenagers are writing software that's easier to use than ours.
What are they doing that we're not?

Rob

[Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMakerin5.8.8 for UINST=1

[demerphq <dem...@gm...>]

On 2/16/06, Adam Kennedy <cp...@al...> wrote:
> demerphq wrote:
> > On 2/15/06, John Peacock <jpe...@ro...> wrote:
> >> Adam Kennedy wrote:
> >>>> to be even easier.  But "perl Build.PL; ./Build test; sudo ./Build
> >>>> install" is a close second.
> >>> That doesn't work for me, 50% of my machines require an alternative
> >>> syntax of
> >>>
> >>> C:\Program Files... etc etc
> >> Directories with spaces are evil (but I'm sure you know that already).
> >> Build.cmd (or Build.bat) support may or may not make it into M::B 0.28=
,
> >> depending on how motivated people are, since Ken/Randy are trying to g=
et 0.28
> >> out the door RSN.
> >>
> >
> > Actually i think that this is not that well known advice and it should
> > probably be added to the perl docs.
> >
> > Perl and everything that Perl uses for installation via CPAN should be
> > installed ONLY into spaceless paths (in you want a low pain life that
> > is). The easiest way to make your CPAN life hell is to put your
> > compiler (im my case VC7) in a path with spaces in it.
> >
> > IIRC the AS installer defaults to a non space path. C:\Perl iirc (i
> > usually override this so i dont remember for sure).
> >
> > Although Adam, i think its fair to say that in your case you should jus=
t do
> >
> > set path=3D%path%;LOCATIONOFYOURPERL
> >
> > before you use MB.
>
> The problem is not me personally.
>
> Like pretty much every person on this list, I know enough to work around
> such problems when they come up.
>
> The problem is for people that aren't on this list. At Sydney.pm last
> night I met one of the maintainers of TWiki. It was enlightenment.

Ok. Im sorry, i had the impression you were mostly dealing on a work
context where many machines are present. Of course these things are
trial and error for a newbie. And also the docs could be more helpful
in this area.

> For his userbase, the "things we don't tell you about using
> Module::Build" would look like.
>
> - The zip file won't work on its own, you need to install this thing
> called Perl first.
> - You can't click anything, you have to go to start -> run and type in
> arcane commands.
> - You can't install Perl in the normal Program Files location, you have
> to install it in c:\perl like an old DOS program.
> - You have to answer a whole bunch of technical jargon-loaded questions
> in the CPAN(PLUS) first-time process.

To be fair to the Module::Build crew I think its worth pointing out
that the above applies to any install that happens via CPAN, and at
least one of those points applies even to ppm.

> - You can't install modules with Build.PL using the CPAN installers that
> come with Perl, you have to upgrade them first.
> - You can't install modules with Build.PL through the CPAN installer,
> you have to manually install Module::Build directly first.

Ok, these are MB issues in my mind. And are consequences of what i
consider to be bad design decisions early in the process.

> This sort of situation is why we try to place a focus on making it
> easier for the users. What's the point of making things easier for
> authors if you end up serially annoying or altogether excluding 99% fo
> the potential userbase.

Yes i agree.  In my view this has been the main misunderstanding of
the MB project. The folks involved were very focued on author related
concerns to the detriment of user related concerns. And typically when
MB was criticised someone would come out of the woodwork and tell us
how happy we should be as MB was much easier to extend and that we
should just get used to MB because it was the future. (We even saw
something along those lines in this thread.)

The problem is they didnt seem to grok that very few of us cared if MB
was easier to extend or maintain than EUMM was.  All we wanted to do
was install some package on CPAN using the usual tools and were
prevented from doing so because MB was in the picture somewhere.

And in my mind, the author focus had some interesting consequences.
Users are generally not that clueful, and people trying to install a
module because it supposedly solves some problem that they need to
solve arent going to spend a lot of time debugging why the module
failed. What they would see is a failure and that module build was
involved and that any time they expended on figuring out why would be
wasted when they could just go and find a different module. So no bug
reports. (Or rather less bug reports than they probably needed). Not
only that but author level users are more likely to have taken time
and care in setting up their system, so the feedback there was
probably less typical than it would have been if every install failure
had been reported.

Expecting users trying to install module X to diagnose and the report
a failure in Y that is only in the picture because its the installer
is unrealistic. Only a module author level programmer has the skills
to even begin the process, and even there that assumes they have time
to do so. What i reckon is much more likely is that there are a lot of
MB related bugs filed against various module X's out there, and much
less reports directly to MB.

I mostly write this because I think that there are lessons to be
learned from this. MB is a good idea, everybody who has had to fight
with EUMM knows that. But the project made some signifigant mistakes
that should be noted and learned from.

Yves

--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

[Module::Build] Build clean demands re-run

[<and...@fr...>]

This is certainly a low priority job, but one might still think about
it:

 % ./Build clean                          
 * ERROR: Configuration was initially created with Module::Build version '0.2611',
   but we are now using version '0.2707'.  Please re-run the Build.PL or Makefile.PL script.

Maybe the clean target can be exempted from this re-run eagerness?

-- 
andreas

Re: [Module::Build] Broken test in runthrough.t

[Ken W. <ke...@ma...>]

On Feb 14, 2006, at 5:22 AM, John Peacock wrote:

> Andreas J. Koenig wrote:
>> The following test is broken in bleadperl:
>>
>>   my $fh = IO::File->new(File::Spec->catfile($dist->dirname, 
>> 'META.yml'));
>>   my $contents = do {local $/; <$fh>};
>>   $contents =~ /Module::Build version ([0-9_.]+)/m;
>>   is $1, $mb->VERSION, "Check version used to create META.yml: $1 == 
>> " . $mb->VERSION;
>>
>> The last line should compensate for trailing zeroes:
>>
>>   is 0+$1, 0+$mb->VERSION, "Check version used to create META.yml: $1 
>> == " . $mb->VERSION;
>
> Or better yet, stop doing *string* comparison with *numbers* (or 
> $VERSION's):

In my defense, all I was doing is setting a variable and checking its 
value later after it passed through a file, so the natural comparison 
seemed to be a string comparison.

In any case, I'm checking in the first part of the patch now, before I 
start thinking about the other parts.

  -Ken

Index: t/runthrough.t
===================================================================
RCS file: /cvsroot/module-build/Module-Build/t/runthrough.t,v
retrieving revision 1.64
diff -u -r1.64 runthrough.t
--- t/runthrough.t	9 Jan 2006 03:58:01 -0000	1.64
+++ t/runthrough.t	16 Feb 2006 04:05:09 -0000
@@ -139,7 +139,7 @@
    my $fh = IO::File->new(File::Spec->catfile($dist->dirname, 
'META.yml'));
    my $contents = do {local $/; <$fh>};
    $contents =~ /Module::Build version ([0-9_.]+)/m;
-  is $1, $mb->VERSION, "Check version used to create META.yml: $1 == " 
. $mb->VERSION;
+  cmp_ok $1, '==', $mb->VERSION, "Check version used to create 
META.yml: $1 == " . $mb->VERSION;

    SKIP: {
      skip( "not sure if we can create a tarball on this platform", 1 )

Re: [Module::Build] Does ./Build work on Windows?

[Ken W. <ke...@ma...>]

Okay, I'm about to commit this patch.  I had some trouble applying it 
because there seemed to have been some whitespace differences, not that 
I could actually find them, so I applied by hand.  You might want to 
look at it after I applied to make sure it works properly.

  -Ken


On Jan 30, 2006, at 3:11 AM, demerphq wrote:

> The change required to MB to handle this is minimal and is implemented
> in a provisional form in the attached patch.
>
> When the Build script is created it needs to add the line
>
>   close *DATA unless eof(*DATA);
>
> when being used on win32. Then the exception line in pl2script needs
> to be removed.
>
> Additionally when scripts are pl2bat'ed their bat names need to be
> added to the cleanup list. This currently doesnt happen at all so MB
> cant/doesnt clean up pl2batted files properly. (It may do so
> indirectly as a directory cleanup but this doesnt help the build
> script itself.)
>
> Also, my preference (and i think the preference of many in the windows
> world) is to avoid ".bat" files on NT and latter Win32 OS'es. It
> should use the .cmd extension when on NT, W2K and XP or later.  I
> hazzily recall there is a good reason for this, but i have to admit I
> dont remember what it is. Maybe its just cargo cultism and doesnt
> matter at all. Anyway, the point is the attached patch includes such
> logic. :-) I based it the behaviour change on the presence of .CMD in
> the PATHEXT enviornment var so on machines without either it will
> default to .bat
>
> Im sorry i havent gotten further on this, i was distracted by other 
> things.
>
> BTW, there is one annoying thing about self deletion of the .cmd/.bat
> Build file. When control returns to the shell it raises a warning
> about the batch file unexpected ending. Its not an issue, but it is
> inelegant so figuring out how to make it go away would be nice.
>
> Er, also, it might be worth just replacing the pl2bat behaviour with
> the creation of a generic Build.cmd that just contained the logic to
> launch perl Build. Then it wouldnt need to be cleaned up, and avoid
> the other little issues involved.
>
> Cheers,
> yves
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
> <mb.patch>

[Module::Build] SWIG compilation support and order of extra_compile_flags in compile_c

[R. B. <ro...@pa...>]

I submitted in ticket 17666 on rt.cpan.org a sample Build.PL that
handles SWIG compilation via subclassing, but might be better to have
this as common code part of the package. 

But one little thing I noticed in this endeavor was that for SWIG
compilation it is helpful to turn off some gcc warning messages until
such time SWIG is fixed to not cause gcc to emit them. So I changed
the order of applying user cflags (extra_compiler_flags) to come
*after* the cflags that are picked up as part of the Perl
configuration. Another possibility is to add a new option to allow
cflags specified before and afterwards.

Thanks.

[Module::Build] version.pm support

[John P. <jpe...@ro...>]

Attached is a fully working patch for implementing version.pm object 
support within Module::Build.  NOTE: this requires bumping the minimum 
version of YAML to 0.50 or better (to get the object stringify support).

I haven't eliminated the compare_versions() sub, but I can if the 
attached patch is acceptable.  I will also try to move the prerequisites 
version range code into the Module::Build::version package.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

[Module::Build] Re: [Yaml-core] yaml_dump on version objects

[John P. <jpe...@ro...>]

John Peacock wrote:
> Dear Perl YAML-heads:
> 
> I've been trying to integrate version objects into Module::Build (now 
> that I have a pure Perl release) and everything works except that YAML 
> emits lots of warnings when trying to dump version objects:

Never mind.  Upgrading YAML to current (0.58) works much better and 
setting $YAML::Stringify does exactly what we want.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[Chris D. <ch...@cl...>]

On Feb 15, 2006, at 2:17 PM, demerphq wrote:

> On 2/15/06, Chris Dolan <ch...@cl...> wrote:
>> On Feb 15, 2006, at 1:00 PM, Rob Kinyon wrote:
>>
>>> I may just be echoing commonly-held sentiment, but if 0.28 is being
>>> held up because there's a bug in CPANPLUS, that's annoying.  
>>> Neither I
>>> nor anyone I know even uses CPANPLUS.
>>
>> Neither I nor anyone I know even uses Solaris.  Nonetheless, I would
>> not recommend shipping 0.28 if it were broken under Solaris
>> (hypothetically speaking).
>>
>> Just another CPANPLUS user,
>
> So then why dont you help the MB folks sort out this problem?
>
> Yves

The key word is "user".  I've contributed bug fixes to both M::B and  
CP+ in the past, but I simply don't understand the M::B <-> CP+  
interaction well enough to fix it myself.

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[demerphq <dem...@gm...>]

On 2/15/06, Chris Dolan <ch...@cl...> wrote:
> On Feb 15, 2006, at 1:00 PM, Rob Kinyon wrote:
>
> > I may just be echoing commonly-held sentiment, but if 0.28 is being
> > held up because there's a bug in CPANPLUS, that's annoying. Neither I
> > nor anyone I know even uses CPANPLUS.
>
> Neither I nor anyone I know even uses Solaris.  Nonetheless, I would
> not recommend shipping 0.28 if it were broken under Solaris
> (hypothetically speaking).
>
> Just another CPANPLUS user,

So then why dont you help the MB folks sort out this problem?

Yves

--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"