Re: C++ support
Hey folks, This patch needs a review of somebody who understands XS and C++. Vladimir's done what looks to me like good work and I'd like to incorporate it so he does more. It's a small amount of change and shouldn't take long to look over. https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/45 Schwern On 2/17/13 11:51 AM, Vladimir Timofeev wrote: Hi, please review pull request https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/45 This patch make suffix of target for .xs file processing configurable (defaults .c as before). But now we really can make process .xs files to .cpp (for example) to support C++. Before this change I found two methods to work with C++ in .xs (both are defective in some ways): 1. Use CC='g++' parameter. Bad, because C++ compiler not always gcc (it may be clang, microsoft compiler or any other). 2. Use CCFLAGS with -x c++ it at least works for gcc and clang (may be in others...) Also not portable... Both solutions will not work if module has mix of .c and .cpp files... because .c files also will be processed as c++ Solution with custom subclassing of EUMM works, but it is very ugly (see my post about https://plus.google.com/110578993733685478222/posts/fvisV7ktDtd ) So I propose to remove hardcode of .c suffix of xs targets and make it configurable. It is small change, but will make life of C++ module writers math easy.
ExtUtils::MakeMaker needs a release BY YOU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, 5.18.0 needs a MakeMaker release in order to fix some hash order bugs. Fortunately, its all already been patched in, its just a matter of us putting out an alpha, testing it, and then putting out a stable. And I'm not doing it. Been doing it too long, I'm just getting in the way. I'd like somebody to step up and offer to do the next stable. To that end, I've written down how to do it as best I can. Here's how you make a release, in general. https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/wiki/How-To-Make-A-Release And here's the special considerations for a stable release. https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/wiki/How-To-Make-A-Stable-Release An alpha release isn't much different from releasing any other CPAN module. A stable release involves a bit more rigor, but that's mostly reading CPAN Testers. And I'll be happy to be available as a resource and answer questions and hold hands. So, who wants to make a MakeMaker release? - Original Message Subject: ExtUtils::MakeMaker Date: Wed, 6 Mar 2013 10:38:29 -0500 From: Ricardo Signes r...@cpan.org To: Michael Schwern schw...@pobox.com Perl 5.18.0 is very likely to include improvements to hash traversal randomness. Right now, I believe the only part of the core left that has not been patched in blead is ExtUtils::MakeMaker. I see at https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commits/master that you've merged the work from Yves Oton to fix the bugs made visible by the changes to perl. Can we expect a release of EUMM more or less immediately? If not, we'll apply these patches in blead and create a _0x version number, which I am really not eager to do. - -- rjbs -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQ7/qAAoJEJxzdbWzfct37rUH/RwHuCJcDdFydWoltV5tHVq4 Rfk17hCN7ZZP3Bsd2GQT/0xRqqcycck4JGeHmtypZTtzCv9Eg3wlK67uWDasCogV iSs/wHSyffx/25C0JKZ7Wjag1U//G+HLQSopTXnAf9PSmTM3o5eE46E/9DjcC29W cf0K+NqgWk0vjW1Ez+XzOSBwki0EKz68MJxOf5lgwvs1yIt/Qjm62WCPmMdZRuNd /WF2ojp+pCWD5Rat5rnpFricTQeUSEoJ7FF3y7fzpzVARRE1ujAgDOcACU0OgcC4 ibHcYjGZQFU1S3d6F6mYKigxiMpEkCm/yj+TTs/sL9Nn0E/SsP630C2PJfTALQ8= =umdv -END PGP SIGNATURE-
Re: How To Build A Perl Package Database
On 2012.12.16 1:10 PM, Leon Timmermans wrote: On Sun, Dec 16, 2012 at 6:34 PM, Johan Vromans jvrom...@squirrel.nl wrote: Debian, and most other systems have decent package- and install managers. *They* maintain the database with installed distributions, releases and files. The only good approach for us is to play with them. So, an enhanced META.yaml or whatsoever may be a good idea, but *only* to generate a deb control file, or rpm spec file, or innosetup file and so on. It is no longer neccessary to handle everything ourselves. We're not alone anymore. There are many ways to deploy stuff, not everyone uses rpm/deb, there are good reasons not to do so: for starters it assumes you have root privileges. I agree with Johan that there are better ways to do this. I also agree with Leon that they are not available to all users and operating systems. I would much, much rather use an existing, reliable system than build our own. Really really really! But Perl is a cross platform, cross environment language. Not all the environments we work with have good package managers. Off the top of my head: Windows, a huge, hidden number of our users, has nothing usable and the Solaris package manger is a joke. Not all users in those environments have access to those package managers. Not everybody wants to use them to manage Perl. For example, cpan2rpm is a commendable effort but also a nightmare. In addition, there are some people who live on one OS and are happy and comfortable with how that OS does things. And there are people who happily jump from OS to OS and want to do things the Perl way. Its nice to be able to sit down on any given machine, grab cpanm, perlbrew and local::lib and get everything running smoothly. OS packages are oriented towards one install per machine. Perl is per project and/or per user. Furthermore, Perl is part of the operating system. Making the needs of your project not conflict with the needs of the operating system is tricky. There are ways to shoehorn OS packages to do these things, but it doesn't work well, many admins don't know how to do that, and its different from OS to OS. If none of that convinces you, I'll say this: we've been advancing the build OS packages route for years now and its never really worked. There's tons of Perl shops out there with tangled, messed up Perl/CPAN installations who find it difficult to upgrade in part because they can't replicate their installation. My current client is one of them. My best practice for dealing with big Perl installs is to make one giant OS package of a non-system perl and all the necessary CPAN modules rather than making individual CPAN module packages and their interdependencies come out right. This is kind of gross, but its manageable. Most shops that make it work have a Perl expert on hand. They should not need one. This is in no way in conflict with advancing cpan2package tools. If done right the package database will make packaging Perl modules *easier*. Those same hooks and APIs I talked about to allow for enhanced package database functionality could also be used by OS build systems. The needs of the package database will force modules to become more normalized and provide more and better meta data. At worst, it won't make it any more difficult. Open Source is not a zero sum game. -- The interface should be as clean as newly fallen snow and its behavior as explicit as Japanese eel porn.
Re: How do I arrange for Makefile.PL to create a modulino instance script?
On 2012.8.25 4:04 PM, David Christensen wrote: I am working on a modulino [1] and would like to use ExtUtils::MakeMaker to generate a Makefile such that make (or make all) copies the module file (lib/MyModulino.pm) to a script file (perl-bin/mymodulino.pl) and sets the execute bit. I'm not sure why you'd want to turn a .pm file into a program. The simpler way to do it is to use EXE_FILES. Write bin/mymodulino and then add this as an argument to WriteMakefile(). EXE_FILES = [bin/mymodulino], -- Schwern What we learned was if you get confused, grab someone and swing them around a few times -- Life's lessons from square dancing
Blockers for stable?
It's been almost six months since the last stable. I'd like to get one out the door. Do people feel there's anything blocking stable? -- I am somewhat preoccupied telling the laws of physics to shut up and sit down. -- Vaarsuvius, Order of the Stick http://www.giantitp.com/comics/oots0107.html
Re: ExtUtils::MakeMaker, PREFIX and man3
On 2011.12.14 1:13 AM, Martin Becker wrote: This error message looks like coming from Module::Build, not ExtUtils::MakeMaker. Nice catch. Since you are using the cpan tool, you might want to review your CPAN settings. Try the ``o conf'' command from your CPAN shell and check for path names there. Module::Build has quite a number of options controlling where to install things. In your situation, probably --prefix would work with least surprising results; it was designed aiming for compatibility with EUMM's PREFIX argument. To arrange for cpan calling ./Build with a --prefix argument, you could enter ``o conf mbuildpl_arg --prefix ~/perl'' in your CPAN shell. The EUMM equivalent would be ``o conf makepl_arg PREFIX=~/perl''. Likely what's happening here is the CPAN shell is set to prefer the Makefile.PL when it sees both a Makefile.PL and a Build.PL. This means you're using Module::Build's MakeMaker emulation layer which doesn't always work. There's no reason to use that any more. Setting o conf prefer_installer MB in the CPAN shell should solve the problem, in addition to the settings Martin mentioned above. You'll also want to wean yourself away from using PREFIX. It is hard to predict, and MakeMaker and Module::Build don't always do it the same. MakeMaker has INSTALL_BASE and Module::Build has --install_base which are far simpler. local::lib can take care of setting them up. The down side is if you're already using PREFIX, INSTALL_BASE will install to different locations, so you'll have to move your Perl libraries. -- package Outer::Space; use Test::More tests = 9;
Re: Smoke [5.15.4] v5.15.4-39-g293dcbb FAIL(F) openvms V8.4 (IA64/2 cpu)
On 2011.11.5 12:47 PM, Craig A. Berry wrote: I have pushed the following to master, which gets bundles working and allows us to build and pass all tests. Thanks for getting it working. I'll work on removing the Unix file path cheats, that should preclude the need to special case VMS (except for the readdir casing incompatibility). -- ...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
Re: Smoke [5.15.4] v5.15.4-39-g293dcbb FAIL(F) openvms V8.4 (IA64/2 cpu)
On 2011.10.28 7:57 PM, Craig A. Berry wrote: I patched the new MakeMaker failures on VMS at: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/8d4c9962adb0142bfed60c6b5569c8424637df16 Hopefully once the Win32 test failures introduced by 6.63_01 get sorted out there will be a new dev release soonish. Thanks for that. Everything working ok on VMS now? -- 44. I am not the atheist chaplain. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Smoke [blead] v5.15.4-67-gaba0546 FAIL(F) MSWin32 Win2000 SP4 (x86/1 cpu)
On 2011.10.28 3:13 PM, Craig A. Berry wrote: I suspect the commit that is causing trouble on Win32 is this one: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/f4904b4ce499b7f0c420efae69f44e19fe7dd12f For the first problem, because $(ECHO) comes from init_tools() but depends on things that have been moved to init_others(), and for the second problem, because Win32-specific tests expect things in init_others() that have been moved to init_tools(). Not sure if the best solution is to adjust the tests to match the current reality or rejigger which macros come from what function in the override methods in MM_Win32.pm. Right on the nose. I might have to generate more of the Makefile than I thought. -- ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: Serious ExtUtils::MakeMaker bug in 6.58 6.59
On 2011.9.1 1:08 PM, neal rauhauser wrote: I have updated CPAN, tried to 'install ExtUtils::MakeMaker', and tried to build it using /usr/ports/devel/p5-ExtUtils-MakeMaker. All of them on FreeBSD 6.4, 8.2, and OpenBSD 4.9 fail in a similar fashion, hanging on test 3 of 20 in t/INSTALL_BASE.t Sorry for the delay in replying. We've been tracking this one down for a while and found the culprit. FreeBSD has overridden parts of MakeMaker (specifically ExtUtils::Packlist) and their code can get into an infinite loop during the tests. It's just been patched in the repository to work around, disabling FreeBSD's special code which shouldn't have been running during testing anyway. A fix for FreeBSD's code has also been sent to FreeBSD. You can get that from http://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker or wait for the next release. -- 44. I am not the atheist chaplain. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Fwd: How do I *add* to CCFLAGS and LDDLFLAGS
Original Message Subject: MakeMaker Date: Fri, 08 Jul 2011 14:44:59 -0600 From: Todd Freed tfr...@nitrosecurity.com To: schw...@pobox.com Hi, what can I add to my WriteMakefile call to add a few things to CCFLAGS and LDDLFLAGS that will be used in the makefile? I dont want to overwrite them, just add a bit -Todd This e-mail message and any attachments contain information that is confidential and may be privileged. If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to this message or by sending an email to postmas...@nitrosecurity.com, and destroy all copies of this message and any attachments without reading or disclosing them. Thank you.
[ANNOUNCE] ExtUtils::MakeMaker 6.58
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/tree/v6.58 After a year and a half, a new stable release of MakeMaker! It's big. Here's the major changes: * Metafile processing is now handled by CPAN::Meta. This makes it more correct but also more strict. * Many, many Windows fixes. * MYMETA files are now generated recording meta information at the point of install rather than at the point of distribution. * JSON versions of MYMETA and META files are now generated. * AUTHOR now accepts multiple authors. Many thanks to... * Christian Walde, Chorny, David Golden, Matt Trout, Robin Barker, Jens Rehsack, Yasuhiro Matsumoto, Zefram, Adam Kennedy and Reini Urban for their work! 6.58 Wed Jul 6 14:17:06 PDT 2011 No changes since 6.57_11 6.57_11 Thu May 19 17:26:31 PDT 2011 Bug Fixes * Changed CPAN::Meta to accept version objects. [github #16] * Massage bad versions and warn the user about them. [github #15] * Protect against CPAN::Meta dying during metafile validation and generation. VMS * Fix prereq.t to work around local %ENV = %ENV bug Win32 * Liblist::Kid can now recognize long compiler paths (Christian Walde) [github #11] 6.57_10 Sun, 03 Apr 2011 19:36:38 +1000 Bug Fixes * Relaxed strictures on prerequisite versions. Invalid versions now issue a warning and are set to 0 rather than dying. [github #7] * Upgraded CPAN::Meta to 2.110930 which fixes a glitch in writing MYMETA.yml if your module's version number was 1.4. [github #9] * Convert LICENSE entries which are unknown to CPAN::Meta to unknown rather than dying. [github #10] 6.57_09 Mon, 28 Mar 2011 11:13:39 +1100 Misc * Make CPAN ignore bundled modules * Accidentally rolled Version::Requirements into the version bundle * Deleted now unused ExtUtils::MakeMaker::YAML 6.57_08 Sun, 27 Mar 2011 21:52:47 +1100 VMS * Removed dependency on cc_runtime.h for VMS as well. Misc * Changed how modules are bundled to avoid replacing XS version of Scalar::Util with a pure Perl version [github #4] 6.57_07 Fri, 25 Mar 2011 14:31:31 +1100 Enhancements * Generates META.json and MYMETA.json in addition to META.yml and MYMETA.yml (David Golden) * MYMETA has the runtime requirements made priority over META_* keys to allow generation of a correct META.* into the dist while still generating an accurate MYMETA.* locally (Matt S Trout) * Distributions should not depend on cc_runtime.h from core as it is only needed for B::CC * Now uses CPAN::Meta to generate META files. Bug Fixes * MYMETA.yml generation from META.yml actually works (Matt S Trout) * All required META fields are generated, even if they must be filled with unknown in place of real data (David Golden) Test Fixes * miniperl.t is no longer run outside of the perl core. Its only relevant to bleadperl and requires no backwards compatibility [rt.cpan.org 61868] Cygwin * Rebase behaviour was improved (Reini Urban) * Build man pages (Reini Urban) Win32 * Spot valid lib files on Win32 when .a and .lib are mixed. (Christian Walde) [github #3] * Extensive testing of ExtUtils::Liblist::Kid for Win32 (Christian Walde) * Implemented proper emulation of DOS escaping rules in ExtUtils::MM_Win32 (Christian Walde) 6.57_06 Wed Oct 06 13:49:00 EEST 2010 Win32 * Work around dmake's limitations on how long a line can be. [rt.cpan.org 61286] * ActivePerl 1007 can now see gcc. [rt.cpan.org 55752] (Christian Walde) Bug Fixes * Fix for AUTHOR and undocumented usage of MM-new() (Alexandr Ciornii) 6.57_05 Sat Sep 11 23:24:00 EEST 2010 Bug Fixes * AUTHOR compatibility code should also be called after CONFIGURE callback 6.57_04 Thu Sep 09 23:59:00 EEST 2010 Bug Fixes * Fix several_authors.t * Upgrade bundled modules: ExtUtils::Manifest 1.58. 6.57_03 Thu Sep 09 01:31:00 EEST 2010 Bug Fixes * Update MANIFEST 6.57_02 Wed Sep 08 02:40:00 EEST 2010 Bug Fixes * Don't do MANIFEST checks in PERL_CORE (Robin Barker) New Features * Accept several values (arrayref) in AUTHOR (Alexandr Ciornii) * Add MYMETA.yml support (Adam Kennedy, Alexandr Ciornii) * NO_MYMETA key to suppress MYMETA.yml generation (Alexandr Ciornii) 6.57_01 Tue Aug 24 01:36:20 PDT 2010 Improvements * parse_abstract() is more robust supporting Package.pm and multiple dashes and spaces. [rt.perl.org 74438] Bug Fixes * Recognize .so files in AIX. [rt.cpan.org 41360] (Jens Rehsack) * Remove manual image-base generation on Win32/gcc [rt.cpan.org 47138] (Yasuhiro Matsumoto) * Use the bundled versions of our dependencies if they're not installed. * Eliminate use of foreach qw() which will be deprecated in 5.14. [rt.cpan.org 57124] (Zefram) Test Fixes *
Re: Using Github pull requests with MakeMaker
On 2011.4.18 8:41 AM, Andreas J. Koenig wrote: On Fri, 25 Mar 2011 15:17:27 +1100, Michael G Schwern schw...@pobox.com said: Good? Thoughts? Just a data point. It doesn't work in my firefox, it seems to work in chromium. I roll to disbelieve that Github doesn't work in Firefox. Is it tragically old? Do you have Javascript turned off? Is it otherwise crippled? Is the doesn't work light on your browser flashing or steady? Either way, you may be surprised to find that makemaker@perl.org is not their support queue. It is here: http://support.github.com/ -- But there's no sense crying over every mistake. You just keep on trying till you run out of cake. -- Jonathan Coulton, Still Alive
Re: MakeMaker 6.57_08 (RC1)
On 2011.3.29 10:33 PM, Burak Gürsoy wrote: On Tue, Mar 29, 2011 at 01:27:36PM +1100, Michael G Schwern wrote: After 6.58 MakeMaker will seriously consider shooting 5.6 in the head... I mean ending long term support. That will make shipping Scalar::Util unnecessary. Well, do 5.6 users upgrade their tool chain at all I wonder? They will want to install new modules and CPAN will only give them the latest ones. And you need an older version of Test::More under 5.6 if you're using that for tests IIRC Test::More still works on 5.6 but 2.0 will not. -- Alligator sandwich, and make it snappy!
Re: MakeMaker 6.57_08 (RC1)
On 2011.3.29 5:55 AM, Steffen Mueller wrote: On 03/28/2011 01:38 AM, Michael G Schwern wrote: This release fixes an issue where MakeMaker would overwrite an installed XS version of Scalar::Util with a reduced functionality pure Perl version. It will now only install Scalar::Util if it is missing entirely. This fixes issues with Compress::Zlib and breaking smokers. That only happens on install of MM, right, so it wouldn't be an issue for the core. Yes. And the core will have a newer version of Scalar::Util so it wouldn't trigger it anyway. For the record, the most current Scalar::Util releases do not ship the PP fallback any longer. It simply wasn't worth the hassle considering problems such as this. After 6.58 MakeMaker will seriously consider shooting 5.6 in the head... I mean ending long term support. That will make shipping Scalar::Util unnecessary. -- 29. The Irish MPs are not after Me frosted lucky charms. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
MakeMaker 6.57_09 (RC2) (no runtime code change)
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/tree/v6.57_09 6.57_09 fixes a bunch of little issues having to do with the bundled modules including making this an authorized release and an issue on machines missing Version::Requirements. http://www.cpantesters.org/cpan/report/4ac71d14-5878-11e0-8c36-3c34095336ca There is no runtime code change in this release. If you're doing a long smoke run you can continue to use 6.57_08. 6.57_09 Mon, 28 Mar 2011 11:13:39 +1100 Misc * Make CPAN ignore bundled modules * Accidentally rolled Version::Requirements into the version bundle * Deleted now unused ExtUtils::MakeMaker::YAML 6.57_08 Sun, 27 Mar 2011 21:52:47 +1100 VMS * Removed dependency on cc_runtime.h for VMS as well. Misc * Changed how modules are bundled to avoid replacing XS version of Scalar::Util with a pure Perl version [github #4] -- Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
MakeMaker 6.57_07 (release candidate 0)
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/tree/v6.57_07 A new ExtUtils::MakeMaker alpha has been released, 6.57_07. This is effectively release candidate 0 for 6.58. There has been a lot of change since the last alpha and far more since the last stable. Please load it into your smokers and whatnot and help test it out. Ideally, we'd like to get a 6.58 out in time for 5.14.0. Major changes - David Golden and Matt Trout were busy doing a major overhaul to the meta file generation adding META.json support and normalizing our meta file generation code with the rest of CPAN. Reini Urban made some fixes to Cygwin. Christian Walde fixed and tested Win32 compiler issues. 6.57_07 Fri, 25 Mar 2011 14:31:31 +1100 Enhancements * Generates META.json and MYMETA.json in addition to META.yml and MYMETA.yml (David Golden) * MYMETA has the runtime requirements made priority over META_* keys to allow generation of a correct META.* into the dist while still generating an accurate MYMETA.* locally (Matt S Trout) * Distributions should not depend on cc_runtime.h from core as it is only needed for B::CC * Now uses CPAN::Meta to generate META files. Bug Fixes * MYMETA.yml generation from META.yml actually works (Matt S Trout) * All required META fields are generated, even if they must be filled with unknown in place of real data (David Golden) Test Fixes * miniperl.t is no longer run outside of the perl core. Its only relevant to bleadperl and requires no backwards compatibility [rt.cpan.org 61868] Cygwin * Rebase behaviour was improved (Reini Urban) * Build man pages (Reini Urban) Win32 * Spot valid lib files on Win32 when .a and .lib are mixed. (Christian Walde) [github #3] * Extensive testing of ExtUtils::Liblist::Kid for Win32 (Christian Walde) * Implemented proper emulation of DOS escaping rules in ExtUtils::MM_Win32 (Christian Walde) 6.57_06 Wed Oct 06 13:49:00 EEST 2010 Win32 * Work around dmake's limitations on how long a line can be. [rt.cpan.org 61286] * ActivePerl 1007 can now see gcc. [rt.cpan.org 55752] (Christian Walde) Bug Fixes * Fix for AUTHOR and undocumented usage of MM-new() (Alexandr Ciornii) -- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Using Github pull requests with MakeMaker
Now that we have something like 14 people who have commit bits to the MakeMaker Github repository, it's time to do something aggressive with that. I've been working with Dancer lately and have been really enjoying their aggressive use of Github, particularly pull requests. You can read about it here: http://lumberjaph.net/dancer/2011/03/06/how_to_use_github_effectively_for_your_project.html I'd like MakeMaker to use this model: * Promote collective ownership * Encourage more eyes on major changes * Encourage more code review * More visible conversations about patches * Less patches dropped on the floor Rather than plopping major changes into master they are done in a fork or a branch (or both). Then a pull request is issued on Github. This automatically opens an issue and lets all the repo owners know there's code to be reviewed and merged. Less patches dropped on the floor. Then the fun begins. And I do find it fun. Far more fun than mailing patches around. Github has a number of ways to review and comment on code per commit, line by line, and on the pull request as a whole. This all shows up in the conversation on Github. Even better, any new commits to the branch being pulled also show up in the conversation. Here's an example: https://github.com/sukria/Dancer/pull/410 ambs forked Dancer, made a branch to fix this bug, committed the fix and then issued a pull request. Then I had a look, made some comments on individual lines of the code... https://github.com/sukria/Dancer/pull/410#commitcomment-313252 https://github.com/sukria/Dancer/pull/410#commitcomment-313253 As well as the commit overall. https://github.com/sukria/Dancer/pull/410#commitcomment-313256 ambs replied and made another commit to fix what I'd pointed out. https://github.com/sukria/Dancer/pull/410#commits-pushed-b76a5eb And so on. The end result being to eventually have at least two people with commit bits saying approved and then somebody merges it. For example: https://github.com/sukria/Dancer/pull/408 This avoids surprises without too much bureaucracy. It also allows major changes to be done with lots of eyes on them, or for new codes to be shepherded through. Here's an example from Method::Signatures. https://github.com/schwern/method-signatures/pull/5 Good? Thoughts? -- 29. The Irish MPs are not after Me frosted lucky charms. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Problem packing Java files whose name includes a $
On 2011.3.9 10:01 PM, Antonio Bonifati wrote: I am trying to package some compiled Java anonymous classes within a Perl package but found it to be impossible. I need them because my code uses Inline::Java. The problem lies in the filenames: e.g. they contain $1 (e.g. ClassName$1.class). In the Makefile generated by perl Makefile.PL such file names are not quoted and thus they erroneously become ClassName.class because the special shell variables $1, $2, ... etc are substituted for empty strings. Is there any cure for that other than packaging all my classes as JARs? Quoting the file names containing a $ in the MANIFEST (e.g. 'ClassName$1.class', 'ClassName\$1.class', ClassName\$1.class) does not help here. A filename with a $ in it in a Makefile is going to fall down the stairs and hit its head on every step. That's very non-trivial to fix. MakeMaker is not careful about quoting or escaping filenames. The simplest way out is to use Module::Build which won't have this problem. -- Robrt: People can't win Schwern: No, but they can riot after the game.
Re: Added META.json and MYMETA.json support to EU::MM
On 2011.2.6 11:52 PM, David Golden wrote: The change log says this which needs to be discussed. INCOMPATIBLE CHANGES * META and MYMETA files will only be created if CPAN::Meta is installed to ensure consistent and valid META file generation [David Golden] Making it an optional dep on CPAN::Meta will silently make META files inconsistent on CPAN. I don't have CPAN::Meta installed. If I hadn't looked at the change log I likely wouldn't have noticed until somebody told me my releases were missing their META files. One of the reasons the META file works so well is authors have to do nothing. It could be a PREREQ_PM and still skip tests if not installed. That risks a circular dependency loop which I don't trust CPAN installers, particularly older ones, to gracefully get themselves out of. That would solve the problem for all but the particular case of a local::lib bootstrap of a modern EU::MM into a perl before 5.8.9. And that could be rectified by local::lib also bootstrapping CPAN::Meta once EU::MM is installed. Here are the options I see. First, make it use CPAN::Meta if available and if not fall back to a built in one. MakeMaker already has a copy of YAML::Tiny in ExtUtils::MakeMaker::YAML. The slightly inconsistent data is better than no data at all. No. I'm on a campaign to eradicate copies of YAML::Tiny in core and have Jesse's support for that. We now have CPAN::Meta::YAML and that is the standard tool to be used by everything that needs it. Another option would be to put CPAN::Meta into inc. Unfortunately, CPAN::Meta has dependencies. Can they all be put into inc? CPAN::Meta::Tiny? Yes, everything can be put into inc. The only tricky one is version.pm and even that can have a pure-perl version put there. I haven't tested it that way, but I'm 95% sure it will work. It bloats EU::MM's dist a bit, but that's the price of backwards compatibilty. META generation has to continue to work, and I agree it would be best to have everything normalize on one thing. I went through the process of bundling up all CPAN::Meta's deps into inc. It's not hard, it's this through the whole tree: export MAKEMAKER_SRC=/path/to/makemaker/src export PERL5LIB=$MAKEMAKER_SRC/lib:$MAKEMAKER_SRC/inc/:$MAKEMAKER_SRC/t/lib perl5.6 Makefile.PL LIB=$MAKEMAKER_SRC/inc/ make test make install I've pushed my work so far into a cpan_meta branch. https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commits/cpan_meta I hit a snag on Storable. That isn't core until 5.8 and there's no pure Perl alternative. Something will have to be done about that. Thoughts? -- Stabbing you in the face for your own good.
Re: Added META.json and MYMETA.json support to EU::MM
On 2011.2.6 7:57 AM, David Golden wrote: I've pushed commits to the Perl Toolchain Gang repo on github that add support for creating META.json and MYMETA.json files. In addition, all META file creation now goes through CPAN::Meta to ensure valid, standardized metafiles. Thank you for doing that work! CPAN::Meta is an optional dependency, so tests that would need it just skip if not available. The change log says this which needs to be discussed. INCOMPATIBLE CHANGES * META and MYMETA files will only be created if CPAN::Meta is installed to ensure consistent and valid META file generation [David Golden] Making it an optional dep on CPAN::Meta will silently make META files inconsistent on CPAN. I don't have CPAN::Meta installed. If I hadn't looked at the change log I likely wouldn't have noticed until somebody told me my releases were missing their META files. One of the reasons the META file works so well is authors have to do nothing. Here are the options I see. First, make it use CPAN::Meta if available and if not fall back to a built in one. MakeMaker already has a copy of YAML::Tiny in ExtUtils::MakeMaker::YAML. The slightly inconsistent data is better than no data at all. Another option would be to put CPAN::Meta into inc. Unfortunately, CPAN::Meta has dependencies. Can they all be put into inc? CPAN::Meta::Tiny? Michael -- I think it would be great if we could get a dev version released this week so we can see how it smokes and then merge it into blead if it looks decent. Between work and Test::Builder2, I have no time for MakeMaker. But you have PAUSE co-maint now. -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email?
redo
Saw mjd tweet about a new build system called redo that does two things I've never seen before in a build system. First, it breaks the build process up into files that live alongside the file it's controlling. Want to compile a C program? Write hello.do that compiles hello.c. Want a test target? Write test.do. Where's the code that generates lib/Foo.pm? It's in lib/Foo.pm.do. Second, the do files are just programs. They respond to #!. Even though it was designed with shell in mind (I need to tell the author a few things about shell portability) they're not tied to it. If you're interested in build system, I would highly recommend reading through the README. https://github.com/apenwarr/redo http://apenwarr.ca/log/?m=201012#14 The major downside is all those .do files everywhere. Who's going to write them? Wouldn't it be nice if there was something to GENERATE them? Yes. Indeed. Hmm. Interesting. -- Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: Removing .svn from blib
On 2010.11.3 9:13 PM, Bill Moseley wrote:
MakeMaker does not copy the .svn directories. But Module::Install::Catalyst
uses File::Copy::Recursive which just copies entire directories into blib.
I would consider that a bug in MI::Cat. It should either have its own list or
make use of MM-libscan($path). You should report that to MI::Cat.
Module::Install uses MakeMaker but it is its own thing that MakeMaker has no
control over.
And it does that copy when running Makefile.PL, not at make time so, I
guess I can just prune them in Makefile.PL.
I would also consider that a bug or at least a design flaw in MI::Cat.
Makefile.PL should not be building things or copying stuff into blib.
Pruning them in the Makefile.PL would seem to be the simplest work around.
I also notice .svn directories end up in blib with my share directories in
other distributions (I use File::ShareDir). After I run make the .svn
directories only end up in blib/lib/share/, not any other directories.
File::ShareDir or its Module::Install component may have the same issue as
MI::Cat. I would discuss that with them.
So, in that case I'd need some way to prune the .svn dirs after running make.
The simplest work around for that is to write a postamble method that
introduces your own additions to the pure_all target which is what runs with
make and has pm_to_blib as a dependency.
sub postamble {
return 'MAKE';
pure_all ::
...prune here...
MAKE
}
--
Who invented the eponym?
Re: Removing .svn from blib
On 2010.11.3 3:18 PM, Bill Moseley wrote: Is there a way to get the generated Makefile to remove any .svn dirs? I'm using Module::Install with Module::Install::Catalyst and File::ShareDir and I end up with .svn dirs in blib that then end up getting installed. Can I modify a target (say make) to remove these before installing or building a tarball? MakeMaker should be ignoring .svn directories. They should not be copied into blib. It's possible Module::Install or Module::Install::Catalyst has broken this. I'd recommend trying a straight MakeMaker setup and see if the problem persists. If it doesn't, talk to the MI folks. -- Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: Spaces in file names when running make dist
Hi, We'd need to see your Makefile and Makefile.PL to do a proper diagnosis. MakeMaker's default create_distdir does not directly call mkdir, it uses ExtUtils::Manifest::manicopy(). It's possible an older version of ExtUtils::Manifest had a bug, but it looks more like something modified create_distdir to call mkdir. On 2010.11.3 4:37 PM, Bill Moseley wrote: Seems ok on a newer machine with 6.54. I searched quickly for space in the changes file and didn't see anything. On Wed, Nov 3, 2010 at 4:22 PM, Bill Moseley mose...@hank.org mailto:mose...@hank.org wrote: I assume I'm messing something up here as this doesn't seem likely. $ make dist ... ... mkdir MyApp-0.01/root/static/build/media/press_releases -e: root/static/build/media/press_releases/e0da5df8a1293cef36db6a52de5f91dccb_Current not found at -e line 1 Can't read root/static/build/media/press_releases/e0da5df8a1293cef36db6a52de5f91dccb_Current: No such file or directory make: *** [create_distdir] Error 2 The file has spaces: b...@dev4 ~/MyApp $ ls root/static/build/media/press_releases/e0da5df8a1293cef36db6a52de5f91dccb_Current\ Member\ Publishers.pdf root/static/build/media/press_releases/e0da5df8a1293cef36db6a52de5f91dccb_Current\ Member\ Publishers.pdf $ perl -MExtUtils::MakeMaker -le 'print $ExtUtils::MakeMaker::VERSION' 6.42 $ cat /etc/issue Fedora release 12 (Constantine) Kernel \r on an \m (\l) The file was correctly added with make manifest -- it's the full path in MANIFEST. -- ...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
Re: multiple users cannot do perl installation due to chmod on .bs file
On 2010.10.14 7:32 AM, Manohar Koduru wrote: Then use newgrp to change to that group before installing modules. Even if all people installing perl modules belong to the same group, there can be only one *owner* for the .bs file. So chmod statement in MM_Unix.pm would still fail for all people except for the owner as one needs to be the owner to change permissions of a file. Let me know if I am missing something. You're correct, I thought it was 664. You can pass PERM_RW=664 in to Makefile.PL. Your CPAN shell can be configured to do this for you. On a larger scale, the application of chmod in MakeMaker is pretty slapdash. Its possible it can just assume that the user has their umask set to something safe and leave it at that. -- 31. Not allowed to let sock puppets take responsibility for any of my actions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Repository recasing
I just fixed the casing on the repository name but didn't realize that would mess up git remote links. So if git tells you something like fatal: '/data/repositories/9/9a/82/ca/Perl-Toolchain-Gang/Extutils-MakeMaker.git' does not appear to be a git repository just reset the URL using git remote set-url using the latest one off http://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker Sorry for the inconvenience. -- Whip me, beat me, make my code compatible with VMS!
github bot on #github, MYMETA branch 2
Whoever setup the github bot on #makemaker, awesome! Also to Adam and chorny for hacking on MYMETA in the mymeta_attempt2 branch. -- Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Repository has moved. Spreading the admin load.
The repository is now at: http://github.com/Perl-Toolchain-Gang/Extutils-MakeMaker I'm not going to bother forking and remaking the old location, I'll just get 6.58 out with the new location before anyone really notices. Non-tl;dr version... I accidentally deleted the MakeMaker repository on Github. Whoops. Fortunately its not a big deal so I just pushed my local copy back. But rather than remaking it as MY repository again I took advantage of the new Github Organizations and make the Perl Toolchain Gang organization. The purpose is to spread out administrative responsibility. I can only let people push to my personal repos, they can never administrate and it always has my name on it. With an organization owned repo I can make teams and hand them admin bits or just push bits. So now mst has as much control over the MakeMaker repo as I do. Perl Toolchain Gang is owned by myself and David Golden. This is the power to change teams and add repositories. The MakeMaker Makers have full admin abilities. chorny David Golden Randy Kobes Myself mst The MakeMaker Doers can push. Adam Kennedy Jan Dubois Josh Ben Jore Tokuhiro Matsuno Tim Bunce If Andreas, Craig, Zefram and Andy tell me their Github accounts I'll add them to the Doers or Makers as they like. And anyone else I've missed, too. I'm just kinda doing this from memory and eyeballing who traditionally provides patches. Potentially this can be used to normalize the administration and commit bits for other collectively maintained toolchain modules. If nothing else it lets me spread out responsibility and get my name off the repository as owner. -- 29. The Irish MPs are not after Me frosted lucky charms. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: ExtUtils::MakeMaker wrongly sets MAKE
On 2010.8.16 1:08 PM, Joshua ben Jore wrote:
On Sat, Aug 14, 2010 at 4:18 PM, Daniel Pfeiffer occi...@t-online.de wrote:
From your doc:
MAKE ... Defaults to $Config{make}.
It should default to not being changed, so as to allow the user to choose
which make he wants to use. Essentially you preclude Perl's own
makepp.sourceforge.net from building subdirectories configured by MakeMaker
About $Config{gmake} and not $Config{make},
Just FYI, Perl is apparently buggy in that it will set $Config{gmake}
even when there isn't an appropriate thing there. Tools like EU::MM
must be able to handle a Perl %Config that lies a little because
unfortunately, Perl's %Config lies a little.
MakeMaker does not use $Config{gmake}. The Config docs state that
$Config{gmake} is for Configure's use and is not useful afterwards.
--
Whip me, beat me, make my code compatible with VMS!
Re: ExtUtils::MakeMaker wrongly sets MAKE
On 2010.8.15 4:59 AM, Daniel Pfeiffer wrote:
So there is a chicken/egg problem. At the point Makefile.PL is run it cannot
know what make you are going to use to run the generated Makefile. It has to
make a guess, and $Config{make} is all it has to go on. This is mostly
important to Windows users where dmake and nmake have very different and
incompatible syntaxes for fundamental things, like escape sequences.
$Config{make} is what some far away distributor chose to build perl. It
doesn't say anything about my machine...
There's nothing else to go on. :-/
You could grovel through PATH for things that look like make, but what happens
when you find more than one? (I have at least two on my OS X machine). And
then there's things like the Solaris UCB bizarreness where they basically have
two parallel tool chains (usually Sun's and GNU's).
Reason #23098 why MakeMaker turns out to be a bad idea.
If you're running with something other than $Config{make} you really should
let MakeMaker know by passing in MAKE. It *probably* doesn't matter for
anything but Windows, but I've seen makes do some stupid things.
As for MakeMaker not setting MAKE at all, its not guaranteed that a given
make
variant will set MAKE. Setting MAKE was put in specifically for MMS (a
popular commercial VMS make variant) but I didn't check other variants. See
commit 04be35b73f4eb51d651980e0185b14ff0a87b847 back in 2004.
It may be possible to make that smarter, only set it if necessary, but you'd
need a way to detect that. If you can do some research to show that most
makes set MAKE then it can be made VMS-only code.
Well, ifndef is a gmake speciality. And POSIX doesn't mention MAKE.
Can't use ifndef, its incompatible with other makes and we don't know what
make we're generating the file for. Chicken/egg.
How about configure style testing, unless your variable already points
you to a make that you know needs the setting:
.PHONY: all
all:
echo $(MAKE) result-file
Which make binary do you run that with? Chicken/egg.
In the end, does perl Makefile.PL MAKE=makepp work?
Like I said, no. $(MAKE) contains some magic, which the user should not
have to worry about. Actually there are two differents kinds of magic,
one to bring the whole processing back into one instance of makepp, and,
where it's so screwed that that doesn't work, a different magic falls
back to real recursive processes, but still with makepp.
Is this magic different from gmake's MAKE magic? If so, you're likely to run
into issues beyond MakeMaker.
MakeMaker can *probably* get away with only setting MAKE on VMS, but it would
need to be tested. If you do the cross platform testing (dmake, nmake, gmake,
BSD make) I'll patch it in.
--
125. Two drink limit does not mean two kinds of drinks.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: ExtUtils::MakeMaker wrongly sets MAKE
On 2010.8.14 4:18 PM, Daniel Pfeiffer wrote:
From your doc:
MAKE ... Defaults to $Config{make}.
It should default to not being changed, so as to allow the user to
choose which make he wants to use. Essentially you preclude Perl's own
makepp.sourceforge.net from building subdirectories configured by
MakeMaker :-(
makepp?! Well look at that, its being worked on again. Neat!
So there is a chicken/egg problem. At the point Makefile.PL is run it cannot
know what make you are going to use to run the generated Makefile. It has to
make a guess, and $Config{make} is all it has to go on. This is mostly
important to Windows users where dmake and nmake have very different and
incompatible syntaxes for fundamental things, like escape sequences.
If you're running with something other than $Config{make} you really should
let MakeMaker know by passing in MAKE. It *probably* doesn't matter for
anything but Windows, but I've seen makes do some stupid things.
As for MakeMaker not setting MAKE at all, its not guaranteed that a given make
variant will set MAKE. Setting MAKE was put in specifically for MMS (a
popular commercial VMS make variant) but I didn't check other variants. See
commit 04be35b73f4eb51d651980e0185b14ff0a87b847 back in 2004.
It may be possible to make that smarter, only set it if necessary, but you'd
need a way to detect that. If you can do some research to show that most
makes set MAKE then it can be made VMS-only code.
You do have the undocumented feature of taking MAKE from the
environment, if present.
This is documented in ExtUtils::MakeMaker cleverly hidden in the section
entitled MAKE.
MAKE
Variant of make you intend to run the generated Makefile with. This
parameter lets Makefile.PL know what make quirks to account for when
generating the Makefile.
MakeMaker also honors the MAKE environment variable. This parameter
takes precedent.
This is however not a solution, because
(recursive make being an inherently faulty paradigm, search on the web
for recursive make considered harmful) makepp has some magic in
$(MAKE) to feed the targets back to the main process, which has the
complete view of dependencies. (This is a workaround for legacy builds,
if you write makefiles for makepp, they can be much simpler and cleaner.)
Well, MakeMaker is considered harmful. :) I'm sorry to say that the boat has
lng sailed on that one. The way MakeMaker handles recursive builds is
unlikely to change due to remaining compatible with existing extensions.
In the end, does perl Makefile.PL MAKE=makep work?
PS Tim, Andy and Andreas don't much work on MakeMaker anymore. Direct
discussion to makemaker@perl.org
--
52. Not allowed to yell Take that Cobra at the rifle range.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: PREREQ_FATAL
On 2010.8.3 2:28 PM, Bill Moseley wrote: It's not to test if the module exists, but if the correct version exists. Again, I think the correct thing to do is have a test that checks the feature needed can be used as expected not that we have a specific version. Yes, exactly that. -- 101. I am not allowed to mount a bayonet on a crew-served weapon. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: PREREQ_FATAL
On 2010.7.31 10:08 AM, Bill Moseley wrote: ExtUtils::MakeMaker says fror PREREQ_FATAL Note: see Test::Harness for a shortcut for stopping tests early if you are missing dependencies and are afraid that users might use your module with an incomplete environment. Unless I'm missing something, it seems that reference is long gone. Anyone remember what was suggested? That would be bail out and its Test::More function for invoking it BAIL_OUT(). You rarely need bail out. Assuming full coverage the tests will fail fine on their own when they can't find the required module. Its only to save the user from having to see the same failure over and over. Generally you might have a t/00compile.t test which checks the library compiles and only bail out if that fails. That will run first and end the testing early. Those docs are a bit out of date. I've rewritten them to refer to Test::More's BAIL_OUT. As I might have commented here back in April, the correct approach would be to test for needed features that are supported in a given version of a dependency. But, in reality what happens is a developer needs to use some CPAN module in our code and just looks at the version they are using for their development and adds that to Makefile.PL. They are saying according to my local testing version 1.2.3 of Foo::Bar works with these changes so they just set a dependency on 1.2.3. Yes, much relies on CPAN modules retaining the backwards compatibility. Most do a good job of that. I have a custom script that runs from cron that checks out our app and then runs Makefile.PL and make test and reports any errors to the development team -- the idea is to catch any check ins that break existing tests and alert the developers quickly. So, part of that would be to report any missing dependencies on the test environment. Makefile.PL doesn't return false be default for missing dependencies so that's why I looked at using PREREQ_FATAL. If you're missing dependencies and your tests don't fail, you need better tests. :-/ I highly recommend against hard coding PREREQ_FATAL into your Makefile.PL. It wrecks the normal procedures for resolving dependencies, they depend on Makefile.PL successfully completing and generating a Makefile. Module::Build has an API to check the prerequisites (see prereq_failures() in Module::Build::API) but MakeMaker has no such thing. Generally you screen scrape the output of Makefile.PL. -- Clutter and overload are not an attribute of information, they are failures of design -- Edward Tufte
Re: circular requirements
On 2010.6.6 5:43 AM, Geoffrey Leach wrote: Hmmm ... sorry that I was not more clear. Here's what I did. (No need to ask why :-) ExtUtils::MakeMaker was previously installed from the Fedora 12 rpm. I removed it. There was no ExtUtils::Installed. Then I attempted to install ExtUtils::MakeMaker using the cpan script. It failed as ExtUtils::Installed.pm was not available. Installing ExtUtils::Installed failed as ExtUtils::MakeMaker was not available. Not something that everyone does :-), but I thought you'd want to know. Thanks for the report. We're aware that MakeMaker cause some issues with automatic CPAN packagers. Bootstrapping is a bit messy. Packagers should *delete inc/ before packaging* and fill in the dependencies on ExtUtils::Install, Manifest and Command. ExtUtils::Install, Manifest and Command should *not* be part of a MakeMaker package. I've written up some basic instructions in an INSTALL file. http://github.com/schwern/extutils-makemaker/raw/master/INSTALL -- 170. Not allowed to defect to OPFOR during training missions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Detecting where files will be placed
Alberto Simões wrote:
I am trying o prepare an installation script that needs to install some
data files and some private binaries. For that it would be great to
substitute on public binaries the base path where the private binaries
will be placed.
With all this site, vendor and perl paths I never know where it will be
placed.
Is there any easy way to find it out during installation step?
So, if I understand you, if programs were going into /usr/local/bin you might
want to go into /usr/local/bin/private?
Other than messing with INSTALL_$(INSTALLDIRS)... rules?
There's a double whammy. First, you have to look at $mm-{INSTALLDIRS} to
figure out what set of install directories you're going to. Then you need to
figure out what set of install variables this maps to (for example, perl
maps to INSTALLPRIVLIB and INSTALLBIN but site maps to INSTALLSITELIB and
INSTALLSITEBIN). And for the final insult, you have to expand any make
variables inside $mm-{INSTALLBIN} yourself. For example, if a PREFIX is set,
$mm-{INSTALLBIN} might be '$(PERLPREFIX)/bin'. MM_Any has a private
_expand_macros() method you can crib from.
Once you have that, you can modify it to your liking and add a postamble()
which extends pure_install.
Or maybe Module::Install has something to handle this.
In Module::Build you follow these instructions to add a new install type.
http://search.cpan.org/~dagolden/Module-Build-0.3603/lib/Module/Build/Cookbook.pm#Adding_new_elements_to_the_install_process
Then you call $builder-install_destination(bin) to get the install location
and modify it to your liking.
(please, do not answer to switch to MB. I have too much things ready to
go over the hedge).
I'm sorry, I cannot delete the above MB recommendation in strict compliance
with Sarbanes-Oxley data archiving regulations.
--
I went to college, which is a lot like being in the Army, except when
stupid people yell at me for stupid things, I can hit them.
-- Jonathan Schwarz
Live MakeMaker - Module::Build conversion (was Re: Detecting where files will be placed)
If anyone is interested, Alberto and I did a live conversion of his Makefile.PL to Build.PL on Etherpad. You can watch the playback here. Shame it doesn't include the chat log. http://etherpad.com/ep/pad/view/ozYkp1OVaK/latest Converting from MakeMaker to MB was the easy part. Figuring out how to get MB to install custom files was more difficult. The MB cookbook has some conflicting/confusing instructions and you get to see a lot of fumbling as we try different things. But once figured out it was fairly simple. A lot simpler than the equivalent MakeMaker mess. We stopped once it was working, there's a lot of cleanup that Alberto can do on his own. In particular, using a real subclass instead of an inline one, and moving the calls to get the treebuilder code inside the process_tree* methods so they fire when the module is built and not when Build.PL runs. -- 60. The Giant Space Ants are not at the top of my chain of command. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Windows expert needed on this one (Re: '()' escaped to '\(\)' is breaking my build)
Dave Anderson wrote: I attached a .zip of Makefile.PL, Makefile, and error.txt which is text from my command prompt. Thanks. Poking through the code, the quoting is done by ExtUtils::MM_Unix-quote_paren() which pretty much just applies it to everything in the const_config section. Its been doing that since before I have history. There's no special cases in it for Windows. The simple fix would be to use the platform specific quote_literal() instead of the generic quote_paren(). quote_literal() would have to be fixed to guard against parens as necessary. Here's the problem, two problems. First, Windows has a lot of different quoting rules. They seem to go by what variant of make you're using and maybe particular version of Windows. I'm no expert. I'm not sure if its really safe to let parens go unescaped in general. Then there's that the macros in const_config are going to be used by a lot of things, so there's a potentially large downstream impact of this change. It could break a lot of things. I don't want to do that at this point in MakeMaker's maturity. Blarf. Normally I'd say don't use a directory with parens in it but that directory seems to be some standard Windows 2000 thing. I also see more than a few tools choke on it. Can you write your module with Module::Build instead? That will be much better suited to dealing with weird characters, since its not trying to write out in nine different formats. A work around for you would be to use replace quote_paren() with $self-quote_literal() in MM_Unix-const_config(). Sorry I don't have a better answer. PS Don't send HTML mail to technical mailing lists, its a great source of flame wars. -- 101. I am not allowed to mount a bayonet on a crew-served weapon. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
[ANNOUNCE] ExtUtils::MakeMaker 6.56
This is a stable release of ExtUtils::MakeMaker. Changes since the last stable release are listed below. Notable changes: * New parameter, BUILD_REQUIRES * The new package NAME VERSION syntax is recognized for finding the version * Mingw64 is supported It is available from CPAN or http://github.com/schwern/extutils-makemaker/tree/v6.56 6.56 Thu Dec 17 14:02:14 PST 2009 * Stable release of 6.55_03 6.55_03 Fri Dec 4 23:08:02 PDT 2009 Bug Fixes * BUILD_REQUIRES will not be used when generating ppd, PRINT_PREREQ and 'requires' section of META.yml (Alexandr Ciornii) OS/2 * Better compatibility with miniperl [rt.cpan.org 48534] (Ilya Zakharevich) Win32 * mingw64 support (Sisyphus) * Fixed a typo causing bad Makefiles for Visual C++ users (Steve Hay) New Features * The new package NAME VERSION syntax from 5.11 is now supported by parse_version() and thus VERSION_FROM. The first version declaration, package or $VERSION, is used. (David Golden) 6.55_02 Wed Aug 5 00:36:36 PDT 2009 Feature Changes * PREFIX now applies to relative directories. This is a change since 6.20 when they were ignored. Its necessary for relocatable Perls. VMS * Refactoring of MakeMaker Parameters section in 6.55_01 broke VMS. (Craig Berry) 6.55_01 Tue Jul 14 15:53:30 PDT 2009 Test Fixes * The tests got a bit overzealous and removed the LIB environment variable while is necessary for some compilers to work. [rt.cpan.org 47722] (Jan Dubois) * Another fix for arch_check() on Windows changing how we normalize long and short filenames. [rt.cpan.org 47723] (Jan Dubois) New Features * BUILD_REQUIRES is added, similar to PREREQ_PM but for modules which are necessary to build, but not run, your module. (Alexandr Ciornii) -- package Outer::Space; use Test::More tests = 9;
Re: '()' escaped to '\(\)' is breaking my build
Dave Anderson wrote: The key line is: LDDLFLAGS = '-libpath:c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib The parenthesis are annoyingly escaped when creating the Makefile: LDDLFLAGS = -libpath:c:\Program Files \(x86\)\Microsoft Visual Studio 9.0\VC\lib -libpath:c:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib Which breaks the build on Windows. The INC attribute doesn't do that so why does LDDLFLAGS? I've tried moving those options into LD but it has the same problem. For now I'm going to have to modify the generated Makefile each time I call Makefile.PL. Sorry about that. Please attach your Makefile and a copy of the build error, then we can get started investigating. -- package Outer::Space; use Test::More tests = 9;
MakeMaker 6.56 next week
If nothing goes majorly wrong with 6.55_03 it will be released as 6.56 next week. -- There will be snacks.
Re: ExtUtils::MakeMaker help - PL_FILES
Alberto Simões wrote:
Heyas
Michael G Schwern wrote:
I am using PL_FILES = { foo/bar.PL = foo/bar }, and foo/bar.PL uses a
lateral file (say, ugh.txt) on the distro to build the script foo/bar.
How can I force the dependency, so make knows it should rebuild foo/bar
when I change ugh.txt?
You should be able to add the dep in a postamble.
sub MY::postamble {
return qq[
foo/bar.PL :: ugh.txt
$(NOOP)
];
}
Unfortunately it is not working. Tried also foo/bar :: ugh.txt but
foo/bar is not rebuilt when I change ugh.txt
Ahh, it needs to be added as a dependency on the original statement. That is:
foo/bar :: foo/bar.PL pm_to_blib
$(PERLRUNINST) foo/bar.PL foo/bar
has to be changed to
foo/bar :: foo/bar.PL pm_to_blib ugh.txt
$(PERLRUNINST) foo/bar.PL foo/bar
Unfortunately the only way to do this is to override processPL() and do a s///
on the output of $self-SUPER::processPL.
package MY;
sub processPL {
my $self = shift;
my $make = $self-SUPER::processPL(@_);
$make =~ s{pm_to_blib}{pm_to_blib ugh.txt};
return $make;
}
This simple s/// will break if you have more than one PL file. Repairing it
is left as an exercise for the reader.
--
E: Would you want to maintain a 5000 line Perl program?
d: Why would you write a 5000 line program?
Re: ExtUtils::MakeMaker help - PL_FILES
Alberto Simões wrote:
Hello,
I am using PL_FILES = { foo/bar.PL = foo/bar }, and foo/bar.PL uses a
lateral file (say, ugh.txt) on the distro to build the script foo/bar.
How can I force the dependency, so make knows it should rebuild foo/bar
when I change ugh.txt?
At the moment I need to make clean, perl Mkefile.PL, make...
You should be able to add the dep in a postamble.
sub MY::postamble {
return qq[
foo/bar.PL :: ugh.txt
$(NOOP)
];
}
--
10. Not allowed to purchase anyone's soul on government time.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Prefixification and relative directories (Re: any 5.10.1 showstoppers?)
Oh goodie, another special case for prefixificaiton.
MakeMaker does not prefix relative directories. The reasoning is lost,
there's just this:
---
commit 2011f6497b6a2f94ae670bb3208d7bff80dbad33
Author: Michael G Schwern schw...@pobox.com
Date: Tue Nov 4 00:13:05 2003 +
- Fixing minor bug in VMS prefixification logic when PREFIX was not set
by the user.
- Fixing potential bug in prefixification for relative directories
Basically, we check $self-{ARGS}{PREFIX} first to see if prefixification
is necessary. We also don't bother to prefixify relative directories.
git-svn-id: http://svn.schwern.org/repos/CPAN/ExtUtils-MakeMaker/tr...@1812
8151f2b9-fde8-0310-94fd-f048d12aab9e
---
Encountering a perl with a relative @INC was never considered. In fact, it
seems the tests are being run while Perl has an @INC that includes things
which are not even valid paths! This doesn't seem like such a hot idea.
Anyhow, I don't remember why prefixification didn't apply to relative
directories so I'll just remove that.
I've committed it and pushed out 6.55_02.
--
7. Not allowed to add In accordance with the prophesy to the end of
answers I give to a question an officer asks me.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: Prefixification and relative directories (Re: any 5.10.1 showstoppers?)
Dave Mitchell wrote:
I tried applying it to blead, but got lots of test failures in
lib/ExtUtils/t/00compile.t:
I guess that explains what all that code in 00compile.t that I tore out was
doing. Here it is back.
--- 00compile.t
+++ 00compile.t
@@ -20,9 +20,10 @@ BEGIN {
chdir ..;
my $manifest = MANIFEST;
open(my $manifest_fh, , $manifest) or die Can't open $manifest: $!;
-my @modules = map { m{^lib/(\S+)}; $1 }
- grep { m{^lib/\S+\.pm} }
- $manifest_fh;
+my @modules = map { m{^lib/(\S+)}; $1 }
+ grep { m{^lib/ExtUtils/\S*\.pm} }
+ grep { !m{/t/} } $manifest_fh;
+
chomp @modules;
close $manifest_fh;
--
91. I am not authorized to initiate Jihad.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: any 5.10.1 showstoppers?
demerphq wrote: Actually, ive been meaning to chase something related to that, in that some time back I did some slicing and dicing of some of the test files in the core that are shared by EUMM and EUI to make it easier to construct the EUMM and EUI from the core files properly, but it seems maybe these changes were not pushed to EUMM even though Schwern was advised of them, and I think later on they were overwritten by somebody doing a naive copy EUMM into core. So its actually possible that EUI isnt being properly tested in core anymore. I need to dig further today. I decided against taking it upstream as it made basic.t, the most complicated test, even more complicated. The plan for core moving forward, as far as I'm concerned, is to put all dual-life modules into their own ext/ directory and stop scattering tests around lib/ and then the problem of clashing goes away. This was done back in March but held up pending 5.10.1. http://github.com/schwern/perl/tree/ext_tests -- Look at me talking when there's science to do. When I look out there it makes me glad I'm not you. I've experiments to be run. There is research to be done On the people who are still alive. -- Jonathan Coulton, Still Alive
basic.t (was Re: any 5.10.1 showstoppers?)
Moving this off p5p. Here's the wrap up. Its bad to have EUI so tightly integrated with MM. Its bad enough that they have a circular dependency, but a circular test dependency is worse. Most of basic.t has nothing to do with EUI. The rest is testing EUI through MM. Testing one piece of software through another is awkward. EUI is effectively testing the MakeMaker interface to EUI. That's MakeMaker's job. What I realize now is that EUI has a perfectly fine interface with which to test itself. There's little reason, other than not having to rewrite the test, that it needs to test itself through MakeMaker at all. Its not its responsible to test its dependents. Once that's done there's no issue nor files to keep in sync. MakeMaker tests its ability to install. EUI tests its own functions and leaves MakeMaker out of the picture. The whole thing will be more robust. There will be very little overlap. Looking at basic.pl I don't see anything its testing about EUI that isn't being tested somewhere else, so I'd just delete it. (As an aside, it will make coverage analysis work since Devel::Cover doesn't see Perl code run in make subprocesses) demerphq wrote: 2009/7/26 Nicholas Clark n...@ccl4.org: On Sun, Jul 26, 2009 at 11:03:21PM +0200, demerphq wrote: Schwern and I will have to sort it out amongst ourselves. And for now im going to leave basic.pl in place even tho it isnt being used, please leave it until schwern and i can negotiate a solution to this. I'm not paying close attention to this (for example, I've deleted the previous messages in this thread, so I can't refer back to them) but I think that Schwern said that the problem may become a lot easier to resolve once dual life modules are detangled from lib and moved each to their own directory in ext/, with their tests run in ext/ I don't agree with that assessment. The reason is you have a test file that now is one third ExtUtils::Install related, and because the other two thirds test EUMM specific functionality it cannot go unchanged into an EUI package without tests failing when someone tries to install the latest EUI with an older EUMM. Thus, even if we do the ext/ thing it doesnt change anything, EUI will need to have the same tests that EUMM has for installation. If the files these test live in are identical then cross-applying patches is trival. If they are quite different, as they would be without taking the tack I did, then getting the same patch to apply to both is a pain (this was the origin of why I did this change). Back when this presented itself I tried to contact Schwern, couldn't find him, and decided to go with what seemed to me to be the better of two options, which was to put some switches in the EUMM version so that the bits that might break in EUI would not fire when run appropriately, and then have the same core file in both, with a preloader to set things up right in each package. Schwern has rejected this, which I guess leaves the option of striping out the install specific tests into a stand alone test file which is the duplicated in EUI and EUMM into a new test file, which is the duplicated in both packages. I personally think the latter is trickier and more timeconsuming than the former. BTW you can see a diff pretty easily: git diff lib/ExtUtils/t/basic.pl lib/ExtUtils/t/basic.t As you can see extracting the stuff that is EUI specific, out of the set up steps needed which will align with EUMM, isnt so easy, which is why I went with the option of selective disablement. Dave asked us not to do this until after 5.10.1 was released. But I think it likely that work will restart rather soon after 5.10.1 Well, as I said, this is irrelevant, some kind of negotiation between Schwern and myself to resolve the this is necessary regardless. Which im sure will happen as soon as we are both in irc at the same time. :-) Yves -- 191. Our Humvees cannot be assembled into a giant battle-robot. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
MakeMaker historical branch
The current MakeMaker repository starts when I took it over back on (oh god has it been seven years) 2002. The files were just copied from bleadperl so there's no previous history in the repository. There is previous history. Andreas provided me with a tarball of tarballs of old releases. Its been lying around moldering here: http://makemaker.org/src/MakeMaker-history/MakeMaker-history.tar Every once in a while I find an issue which I have to dig back through these tarballs to find out what lead a sane citizen of the world to make such a decision. I've wanted this information in version control for a while now so it would just show up as part of an annotate, but previous systems didn't really support the idea of adding history. Fortunately git does. I've created a historical branch and began importing tarballs. I got up to 4.01 before I gave up. If any other obsessive compulsives would like to spend some time doing that it would be nice. The procedure is this. 1) Let us know you're going to work on this to avoid three people all doing the same work. 2) Get and unpack MakeMaker-history.tar. 3) Checkout the historical branch from git. 4) Figure out what the next archive is by looking at the log and the versions on the archives. 5) Uncompress the archive and copy the files (or in some cases, file) in place. 6) Commit everything using... TZ=UTC GIT_AUTHOR_NAME=... GIT_AUTHOR_EMAIL=... GIT_AUTHOR_DATE=... git commit -a At the end of MakeMaker.pm there's a MODIFICATION HISTORY section. This contains the date, author and commit notes. Use the date and author to fill in the author name and author date. For author email, use their modern address which you should be able to find on search.cpan.org. Use the notes as the commit notes. In addition, begin the commit with what archive you got these files from, in case there's a mistake later. From MakeMaker.pm.4.01.gz for example. TZ=UTC GIT_AUTHOR_NAME='Tim Bunce' git_author_email=tim.bu...@pobox.com GIT_AUTHOR_DATE=25.01.1995 For bonus points look at the changes to MakeMaker.pm in the Perl repository and see if there's any parallel history. 7) GOTO 4 until you've done all you're going to do. 8) Send a note to the mailing list where your repo is and how far you got. 9) Send me a pull request. -- THIS I COMMAND!
New commiters to the repo
I've given Craig Berry, Jan Dubois and Alexander Ciornii (aka chorny) commit access to the repo. Craig fixes things on VMS. Jan fixes things on Windows. Chorny stubbornly continues to send in feature patches that I forget to commit. How is this going to work exactly? I'm not entirely sure. Craig and Jan can continue to do their usual thing, patching up their respective OS'. Chorny's feature patches might require more thought and review, he's been patently waiting with a BUILD_REQUIRES patch for a while now. What's nice about github is and change is very visible to me, history can be rewritten, so there's only so bad things can get screwed up. I know how having just one commiter works, and its no secret I'm sick of maintaining MakeMaker, so let's see how having multiple commiters works. And remember, branching means never having to say you're sorry. -- 10. Not allowed to purchase anyone's soul on government time. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
[ANNOUNCE] ExtUtils::MakeMaker 6.53_03
http://github.com/schwern/extutils-makemaker/v6.53_03
This is a release to fix a few test bugs on Cygwin, Windows and OS X. Its a
6.54 release candidate I'm hoping to get into 5.10.1. In particular I need
more Windows testing.
6.53_03 Thu Jul 2 14:47:45 PDT 2009
Bug Fixes
* You'd get a warning if you had a PREREQ_PM on a module with no $VERSION
like Config (broken in 6.51_01) [rt.cpan.org 47448]
Test Fixes
* Upgrade the version of Test::More we ship with to 0.88.
* Fix MM_Cygwin.t for older Perls missing Cygwin::win_to_posix_path()
broken in 6.53_01.
* Fix miniperl.t for Windows. Our method of shutting off XS didn't
work for Win32.pm
* Old versions of version.pm, like what ships with OS X, dent Foo-VERSION
causing prereq.t to fail. [rt.cpan.org 47296]
* Add missing core test boilerplates
[blead e39d780342f3e91579069fdc80eda72bfe639ae7]
6.53_02 Sun Jun 7 19:24:56 PDT 2009
Test Fixes
* Stray use of Shell::Command broke older perls
Other
* MakeMaker will now automatically test itself with multiple
perl versions before releasing.
6.53_01 Sun Jun 7 19:02:20 PDT 2009
Bug Fixes
* blib will now be rebuilt if the Makefile is changed
[rt.cpan.org 46658]
* 6.52 broke the setting of EXTRALIBS, LDLOADLIBS and BSLOADLIBS
when $self-{LIBS}[0] is undefined.
[rt.cpan.org 46633] (Craig Berry)
Cygwin
* Fixed MM_Cygwin.t when the path prefix (ie. cygdrive) has been
changed by the user. [rt.cpan.org 46585] (JDHEDDEN)
VMS
* Removed attempts to compensate for the bin logical added
by some versions of GNV, Craig says they're futile.
Put a warning into the Makefile.PL instead.
[rt.cpan.org 46679] (Craig Berry)
* Removed the arch_check() special case for VMS.
[rt.cpan.org 46678] (Craig Berry)
Win32
* Restore building the core by not trying to load the Win32
module in arch_check() with miniperl.
[rt.cpan.org 46667] (Max Maischein)
Tests
* Forgot to get rid of the tests for bytes and vmsish
which were removed in 6.51_01.
* Stopped running a Windows specific arch_check.t test
on non-Windows. (Craig Berry)
[rt.cpan.org 46678]
6.52 Sat May 30 11:22:04 PDT 2009
Docs
* Documented CONFIGURE_REQUIRES (Alexandr Ciornii)
* Modernized the docs for PREREQ_PM
--
40. I do not have super-powers.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: prerequisite I::Do::Not::Exist 0 not found.
running wrote: It is quite possible. I have the perl that came pre-installed with OSX, that is: Summary of my perl5 (revision 5 version 8 subversion 8) I have found the hard-code fix with my problem - in the file prereq.t, instead of sprintf(Warning: prerequisite strict 9 not found. We have %s.\n, strict-VERSION); that originally was there, and generates: Warning: prerequisite strict 9 not found. We have 1.030. I wrote directly sprintf(Warning: prerequisite strict 9 not found. We have 1.03.\n); The zero at the end seem to be the problem. *headdesk* The purpose of a test is to check if the program is working as expected. If you just change the test to match what happened then the test is pointless. What you did is like trying to put out a fire by turning off the smoke alarm. The test failure indicates there is a small problem with your perl. Its very minor. perl is for some reason sticking an extra 0 on version numbers. It should not be doing that and I'd like to figure out why. Once again, please run this program and send in the output: perl -wle 'use strict ;' and please send me the FULL OUTPUT of perl -V. That's capital V. Then we can figure out what's gone wrong. -- There will be snacks.
Re: prerequisite I::Do::Not::Exist 0 not found.
running wrote: Hello, I am trying to install MakeMaker, What I got after I try make test: t/prereq.t .. 1/13 # Failed test in t/prereq.t at line 60. # got: 'Warning: prerequisite strict 9 not found. We have 1.03. # ' # expected: 'Warning: prerequisite strict 9 not found. We have 1.030. # ' # Failed test in t/prereq.t at line 82. # got: 'Warning: prerequisite I::Do::Not::Exist 0 not found. # Warning: prerequisite strict 9 not found. We have 1.03. # ' # expected: 'Warning: prerequisite I::Do::Not::Exist 0 not found. # Warning: prerequisite strict 9 not found. We have 1.030. # ' # Looks like you failed 2 tests of 13. t/prereq.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/13 subtests I try to install both the latest version from git and 6.53_02, on mac os x 10.5.7, with the same results. I don't have a clue what that message means. Something doesn't exist, apparently. It means there's a minor bug, possibly in your Perl. Its testing that MakeMaker can identify your prerequisites both whether they exist (I::Do::Not::Exist is not supposed to exist) and that you have a high enough version. It seems the formatting of the message on your perl is a bit off. Could you please run: perl -wle 'use strict 9' and let me see the output? Also please attach the output of perl -V. Is this a perl you compiled yourself? -- I'm pale as Formica, social skills stunted small. But I'm accurate like a pica, I know the capital of Nepal. I'm the nemesis of error, dreadful diction fears my skills, more inquisitive than Jim Lehrer, snottier than Beverly Hills. -- I.L.O.P. Secret Rap http://goats.com/archive/020830.html
[ANNOUNCE] ExtUtils::MakeMaker 6.53_02
http://github.com/schwern/extutils-makemaker/tree/v6.53_02
This is an alpha release of MakeMaker, a release candidate for 6.54. Its
mostly fixes to bugs introduced by 6.52 on VMS and Windows while building perl.
6.53_02 Sun Jun 7 19:24:56 PDT 2009
Test Fixes
* Stray use of Shell::Command broke older perls
Other
* MakeMaker will now automatically test itself with multiple
perl versions before releasing.
6.53_01 Sun Jun 7 19:02:20 PDT 2009
Bug Fixes
* blib will now be rebuilt if the Makefile is changed
[rt.cpan.org 46658]
* 6.52 broke the setting of EXTRALIBS, LDLOADLIBS and BSLOADLIBS
when $self-{LIBS}[0] is undefined.
[rt.cpan.org 46633] (Craig Berry)
Cygwin
* Fixed MM_Cygwin.t when the path prefix (ie. cygdrive) has been
changed by the user. [rt.cpan.org 46585] (JDHEDDEN)
VMS
* Removed attempts to compensate for the bin logical added
by some versions of GNV, Craig says they're futile.
Put a warning into the Makefile.PL instead.
[rt.cpan.org 46679] (Craig Berry)
* Removed the arch_check() special case for VMS.
[rt.cpan.org 46678] (Craig Berry)
Win32
* Restore building the core by not trying to load the Win32
module in arch_check() with miniperl.
[rt.cpan.org 46667] (Max Maischein)
Tests
* Forgot to get rid of the tests for bytes and vmsish
which were removed in 6.51_01.
* Stopped running a Windows specific arch_check.t test
on non-Windows. (Craig Berry)
[rt.cpan.org 46678]
6.52 Sat May 30 11:22:04 PDT 2009
Docs
* Documented CONFIGURE_REQUIRES (Alexandr Ciornii)
* Modernized the docs for PREREQ_PM
--
Ahh email, my old friend. Do you know that revenge is a dish that is best
served cold? And it is very cold on the Internet!
Re: Simulating miniperl (was Re: [ANNOUNCE] ExtUtils::MakeMaker 6.52)
Craig A. Berry wrote:
On Sat, Jun 6, 2009 at 12:28 AM, Michael G Schwern schw...@pobox.com wrote:
I'd like to somehow test for this issue without having to shove MakeMaker
into
bleadperl and build it on multiple OS'. [1]
To me that sounds easier than the alternatives. How hard would it be
to fork blead on github, merge in development releases of MakeMaker,
and test MakeMaker in situ rather than relying on a lot of complicated
simulations?
Funny you should ask. http://github.com/schwern/perl/tree/ExtUtils-MakeMaker
The idea there is to develop MakeMaker straight out of a bleadperl fork. That
way anyone can test it, and it keeps in sync with MakeMaker changes from p5p.
I did the experiment months ago. The hard work is done but its being merged
is stalled until 5.10.1 goes out.
You may need less simulation rather than more, but if you want to
pretend you don't have dynamic loading when you actually do, something
like the following should do the trick:
$ perl -e BEGIN {require DynaLoader; *DynaLoader::dl_load_file = 0;}
use Filter::Util::Call;
Excellent, thank you!
Now what needs to be done is write up a miniperl test. Possibly just be
slicing out bits of basic.t (which could use some slicing).
--
164. There is no such thing as a were-virgin.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: [test-more-users] Re: Build bots, smoke servers Smolder
Michael G Schwern wrote: Nicholas Clark wrote: So how do the smokers' systems differ from the clean 5.8.8 that it won't pass tests on? It looks like they all have an upgraded ExtUtils::Install, which one would have if they've installed MakeMaker lately. None are clean builds (I can't tell for most of Bingos' as they aren't reporting deps). I would guess this is because individual smokers simply installed the alphas in a CPAN shell with a dirty 5.8.8 rather than running them through a full clean smoke, which is about all I can expect. It looks like Bingos ran a few through a real smoke run so I don't know what happened there. Turns out it *was* working on 5.8.8, a totally clean 5.8.8 or 5.6.1 will work IF you just unpacked a fresh tarball or ran a make clean. Why? The pm_to_blib target rebuilds blib. It only fires if any of the pm files have changed since the last pm_to_blib run. It doesn't depend on anything else. So, install MakeMaker on 5.10 or something which already has an up to date ExtUtils::Install and it will copy things to blib, but not ExtUtils::Install. Its already up to date. Then, without running clean, rerun Makefile.PL with 5.8.8 and run the tests WITHOUT RUNNING MAKE. None of the pm files have changed to blib does not get rebuilt. ExtUtils::Install is not copied into blib and the tests fail. To replicate: make realclean perl5.10.0 Makefile.PL make perl5.8.8 Makefile.PL make make test Solution: Have pm_to_blib depend on the Makefile. If the Makefile gets rebuilt so does blib. This will probably fix a number of other subtle bugs. Also smoke testing would not have caught this, they're too clean. That explains why there were no failures from Bingos. -- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Simulating miniperl (was Re: [ANNOUNCE] ExtUtils::MakeMaker 6.52)
Steve Peters wrote: It appears that the Win32 change might have been lost. Following the bleadperl update to EU::MM 6.52, bleadperl has been failing on Win32 with the following error. Running Makefile.PL in ext/Win32CORE C:\sandbox\perl-current\win32\..\miniperl.exe -I../../lib Makefile.PL INSTALLDIR S=perl INSTALLMAN1DIR=none INSTALLMAN3DIR=none PERL_CORE=1 LINKTYPE=static Can't locate Win32.pm in @INC (@INC contains: ../../lib C:/sandbox/perl-current/ lib .) at ../../lib/ExtUtils/MM_Win32.pm line 417. 512 from ext/Win32CORE's Makefile.PL at ..\make_ext.pl line 301. Nothing was lost, a new call to Win32.pm was added in arch_check(). Max caught it earlier. https://rt.cpan.org/Ticket/Display.html?id=46667 I'd like to somehow test for this issue without having to shove MakeMaker into bleadperl and build it on multiple OS'. [1] But it's not clear what subset of MakeMaker's functionality needs to work without XS. I guess enough to build modules (the perl build doesn't actually use install, right?) The basic miniperl functionality can be tested with Test::NoXS (copied into t/lib to avoid a dependency). I guess its supposed to work with no XS at all. [1] This will be resolved once my test in situ patch is applied and I can work on MakeMaker directly from inside the perl source. Hint hint! -- Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: Win32, arch_check() and miniperl
Whoops, that should have gone to the bug tracker. Michael G Schwern wrote: Original Message Subject: Re: Restore broken Win32 build Date: Wed, 03 Jun 2009 23:42:13 +0200 From: Max Maischein cor...@corion.net To: Michael G Schwern schw...@pobox.com References: 4a26a5bf.1010...@corion.net 4a26c97d.3020...@pobox.com Hello Michael, the EUMM integration broke the Win32 build with 5bdf71cc9217764029fb9a321295118de3bb8e72 The attached patch restores the building by skipping the loading of Win32.pm Hello, I need to see a bug before I can accept a fix for it. Its broke ain't a bug report. Please excuse the brevity - I wanted to send the patch quickly before I went away from the computer, so the smokers can resume their tasks and I can do some cleanup work integrating some of my tests. Please accept the below output as it's broken when building Perl via `dmake`: -max ... Running Makefile.PL in ext/Win32CORE C:\Projekte\bleadperl-git\win32\..\miniperl.exe -I../../lib Makefile.PL INSTALLD IRS=perl INSTALLMAN1DIR=none INSTALLMAN3DIR=none PERL_CORE=1 LINKTYPE=static Can't locate Win32.pm in @INC (@INC contains: ../../lib ..\..\lib C:/Projekte/bleadperl-git/lib .) at ../../lib/ExtUtils/MM_Win32.pm line 417. 512 from ext/Win32CORE's Makefile.PL at ..\make_ext.pl line 301. -- On error resume stupid
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.51_03
Craig A. Berry wrote:
On Sun, May 24, 2009 at 12:44 AM, Michael G Schwern schw...@pobox.com wrote:
Consider this a release candidate for 6.52. The major change is the
INSTALLHTML* work has been reverted pending a critical bug in order to not
hold up a stable release. I forgot to note that in the change log.
6.51_03 Sat May 23 22:38:26 PDT 2009
Bug Fixes
* Building *.C files was broken in 6.37. [rt.cpan.org 45557]
Thanks to Rajesh Mandalemula for spotting it.
Built against v5.10.0 (GitLive-maint-5.10-1196-ga8a43ff*) built for
VMS_IA64-ithread, I see two test failures. Detailed output below.
I'll try to dig into these more later.
$ perl -I[.blib.arch] -I[.blib.lib] t/build_man.t
1..9
ok 1 - setup
ok 2 - chdir'd to Big-Dummy
ok 3
ok 4
not ok 5
# Failed test in t/build_man.t at line 63.
# Structures begin differing at:
# $got-{[.lib.big]dummy.pm} = '[.blib.man3]big__dummy.rno'
# $expected-{[.lib.big]dummy.pm} = Does not exist
They look related. What's your Config settings for the installman*dir keys?
I made a change to the way MakeMaker deals with them being unset. It used to
set them to 'none' and now it just leaves them blank.
--
package Outer::Space; use Test::More tests = 9;
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.51_03
Craig A. Berry wrote:
not ok 5
# Failed test in t/build_man.t at line 63.
# Structures begin differing at:
# $got-{[.lib.big]dummy.pm} = '[.blib.man3]big__dummy.rno'
# $expected-{[.lib.big]dummy.pm} = Does not exist
They look related. What's your Config settings for the installman*dir keys?
I made a change to the way MakeMaker deals with them being unset. It used to
set them to 'none' and now it just leaves them blank.
$ perl -V:installman1dir
installman1dir='perl_root:[man.man1]';
$ perl -V:installman3dir
installman3dir='perl_root:[man.man3]';
GAH! I released the wrong branch! I'll get a fresh alpha out and patch my
release script to warn me if this happens.
--
E: Would you want to maintain a 5000 line Perl program?
d: Why would you write a 5000 line program?
[ANNOUNCE] ExtUtils::MakeMaker 6.51_04
Whoops, 6.51_03 was accidentally the branch containing the INSTALLHTML* work. 6.51_04 is the master branch and I've changed my release script to warn me if I try to release a non-master branch again. http://github.com/schwern/extutils-makemaker/tarball/v6.51_04 (Looks like github is being slow adding the tarball, should be available shortly) -- Look at me talking when there's science to do. When I look out there it makes me glad I'm not you. I've experiments to be run. There is research to be done On the people who are still alive. -- Jonathan Coulton, Still Alive
[ANNOUNCE] ExtUtils::MakeMaker 6.51_03
Consider this a release candidate for 6.52. The major change is the INSTALLHTML* work has been reverted pending a critical bug in order to not hold up a stable release. I forgot to note that in the change log. 6.51_03 Sat May 23 22:38:26 PDT 2009 Bug Fixes * Building *.C files was broken in 6.37. [rt.cpan.org 45557] Thanks to Rajesh Mandalemula for spotting it. 6.51_02 Mon Apr 13 21:19:56 PDT 2009 Bug Fixes * Fix a minor bug with the new PERM_DIR stuff which caused EUI to think PERM_DIR was an install skip file. * A Win32 function call in the last alpha broke Win32 builds. 6.51_01 Fri Apr 10 14:30:27 PDT 2009 New Features * Module installation will not be stopped by a broken Pod::Man. Man pages will just not be installed. [rt.cpan.org 43546] (Jesse Vincent) * vim swap files, *.swp, will now be ignored by MakeMaker. * Added PERM_DIR to control permissions on directories. [rt.cpan.org 3927] (Rajesh Mandalemula) Feature Changes * Modules in PREREQ_PM are no longer loaded in order to figure out their version. parse_version() is used instead. [rt.cpan.org 44646] * PPD files generated with make ppd now use the new REQUIRES key rather than the now deprecated DEPENDENCY. [rt.cpan.org 25179] (GAAS) * PPD files no longer contain the deprecated OS tag. * fixin is a bit less restrictive allowing things like #!perl5.8.8 and #!perl-debug [rt.cpan.org 29442] * Remove the unused perm_rw() and perm_rwx() methods. Bug Fixes * On 5.10 make ppd would generate the wrong ARCHITECTURE saying the version is 5.1 instead of 5.10. * Our pod2man emulation now requires an argument to --perm_rw. [rt.cpan.org 35190] (imacat) * DISTVNAME was documented as a WriteMakefile() param but you'd get a warning if you tried to use it. [rt.cpan.org 43217] * Better support for parallel make installs. [rt.cpan.org 32758] (Brendan O'Dea) * parse_version() will now skip uses of $VERSION in conditions [rt.cpan.org 9452] (j...@unser.net) * The architecture mismatch warning could show up on Win32 due to long vs short filenames being used to compare. [rt.cpan.org 33532] (DAGOLDEN) * maybe_command() will recognize Windows executables in /cygdrive on Cygwin [rt.cpan.org 16375] (PJF) * parse_version() will now look for the first use of $VERSION that results in $VERSION being set. Test Fixes * basic.t will not leave a bin environment variable defined on VMS. [rt.cpan.org 42150] (John E. Malmberg) * Made the tests work ok on systems whose makes assume that files which have the same mod time are out of date. This is often the case for the tests which generate files and run make rapidly. [rt.cpan.org 29955] (Ken Hirsch) * skip test numbers were wrong on VMS in t/basic.t [rt.cpan.org 43511] (John E. Malmberg) Portability * Removed a few hard coded uses of the false command. [rt.cpan.org 44504] VMS * Fixed a few calls to catfile() that should be catdir(). (John E. Malmberg) * Override catdir() and catfile() to expand macros. This is normally done inside File::Spec::VMS but is really a MakeMaker-only thing. (John E. Malmberg) Other * Remove ExtUtils::MakeMaker::bytes and vmsish which are unused and seem to never have been used. * Repository now on github. 6.50 Sun Mar 22 12:28:06 PDT 2009 Windows * Remove the special checks for compilers that need a manifest. Instead, the code will just be a no-op if there's no manifest. Or something. I dunno, I'm hoping Jan and Steve know what they're doing. [rt.perl.org 61492] -- 24. Must not tell any officer that I am smarter than they are, especially if it's true. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: xs.t without CBuilder (Re: Perl @ 33218)
Craig A. Berry wrote: The attached patch takes a very simplistic approach to skipping the code in the END block when skip_all is in effect -- no doubt the MakeMaker gurus will have a better approach. It does not address the fact that it looks like teardown occurs one directory up from where it should when run as part of the core test suite. Clearing out old MakeMaker mail and came across this one. You're right, and patched in something similar. As for the issue with being in a different place in the core, that will be resolved once the ext/ tests are changed to run in their own directories. -- Schwern What we learned was if you get confused, grab someone and swing them around a few times -- Life's lessons from square dancing
Re: [Win32] Feature request: acknowledge $ENV{LIBRARY_PATH}
Sisyphus wrote: Could the attached patch (against version 6.50 of ExtUtils/Liblist/Kid.pm) be applied ? Patches like these I have no ability to evaluate. I could just take your word on it, but that has a tendency to fix one bug and cause two more. I really, really need someone to take over the XS portions of MakeMaker. Someone who knows C and XS and make and linking all in a cross platform manner. Alternatively, show me that ExtUtils::CBuilder does it (and tests it) and I'll just follow their lead. Or some mad genius could convert MakeMaker to use CBuilder. Good fucking luck. -- Stabbing you in the face for your own good.
MakeMaker is now on github
http://github.com/schwern/extutils-makemaker/ After closing a few dozen MakeMaker tickets in the past week or so, I got sick of applying patches by hand and playing the try this patch game. So I've put MakeMaker on github. This has no impact the plan to use a fork of the Perl github repository. That's held up waiting for the ext test change to be accepted. But there was no reason to keep using Subversion in the meantime. If someone is feeling ambitious, you can try to reconstruct the earlier MakeMaker history from the old tarballs and Perl versions. It would be nice to have full history in the repository, we had to trace an issue back through the tarballs at the QA hackathon. git should allow it to be done a little at a time. http://schwern.org/tmp/MakeMaker-history.tar.gz Other repository gardening would include removing the bogus commits left over from cvs2svn. -- 39. Not allowed to ask for the day off due to religious purposes, on the basis that the world is going to end, more than once. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: MANIFEST.SKIP vs. libscan()
Gary Holloway wrote:
Wouldn't it make sense that if there is a MANIFEST.SKIP file that it
would be honored by libscan() so that files that are to be skipped when
validating the MANIFEST are also not included in the generated makefile
rules (e.g., in the definitions of TO_INST_PM, PM_TO_BLIB) or am I
misunderstanding its purpose?
Scenario: You generate a file but don't want to ship it so you place it into
MANIFEST.SKIP. You still want libscan() to see it.
An example is temporary vim files (e.g., *.swp). If present, they're
found by libscan() and included in TO_INST_PM.
In MM_Unix-init_PM() there is code to skip some common editor backup files.
This should do the trick.
--- a/lib/ExtUtils/MM_Unix.pm
+++ b/lib/ExtUtils/MM_Unix.pm
@@ -1501,8 +1501,9 @@ sub init_PM {
return;
}
return if /\#/;
-return if /~$/;# emacs temp files
-return if /,v$/; # RCS files
+return if /~$/; # emacs temp files
+return if /,v$/;# RCS files
+return if m{\.swp$};# vim swap files
my $path = $File::Find::name;
my $prefix = $self-{INST_LIBDIR};
The (only?) solution I've come up with is creating my own MY::libscan in
Makefile.PL that filters the results from the default libscan
(ExtUtils::MM_any::libscan()) using the regexp's in MAKEFILE.SKIP; like so:
#
=
my $skip;
# Exclude any files matching patterns in the MANIFEST.SKIP file from being
# included in rules in the generated Makefile.
#
sub MY::libscan
{
my $self = shift;
unless (defined $skip) {
# Newer versions of ExtUtils define maniskip(); older versions
(like
# what we're using now) define _maniskip() -- use whatever is
# present, preferring the newer, public, name.
Might be simpler to run skipcheck() and chuck the results into a hash, given
the compatibility issue.
if (defined(ExtUtils::Manifest::maniskip )) {
$skip = ExtUtils::Manifest::maniskip();
} elsif (defined(ExtUtils::Manifest::_maniskip)) {
$skip = ExtUtils::Manifest::_maniskip();
} else {
$skip = undef;
}
}
my $path = ExtUtils::MM_Any::libscan(@_);
There's no guarantee that libscan() will be in MM_Any or that will be your
parent class, so...
my $path = $self-SUPER::libscan(@_);
return ($skip $skip-($path)) ? '' : $path;
}
--
The past has a vote, but not a veto.
-- Mordecai M. Kaplan
Better way to handle Unix compatibility modes must be found
John E. Malmberg wrote:
Are you going to have time to look at the patches that I submitted to
MakeMaker and Test::Simple?
These are to support VMS when the DECC$FILENAME_UNIX_REPORT and
DECC$EFS_CHARSET and related options are active.
These options make Perl on VMS look more like Unix, including returning
filenames in Unix syntax. Path tools has already been updated to work
in this mode.
I had a look at this, and I can't apply it. It was bad enough having special
case code for VMS, now there's three different styles of VMS to be considered.
Here's the mass of detection code:
use VMS::Feature;
my $vms_unix_rpt = VMS::Feature::current(filename_unix_report);
my $vms_efs = VMS::Feature::current(efs_charset);
my $vms_case = VMS::Feature::current(efs_case_preserve);
$Is{VMS_mode} = 0 if $vms_unix_rpt;
$Is{VMS_unix} = 1 if $vms_unix_rpt;
$Is{VMS_lc}= 0 if $vms_case;
$Is{VMS_noefs} = 0 if $vms_efs;
That mercifully doesn't include the work around if VMS::Feature isn't there.
There's no way to expect Perl programmers to stick all that in their code just
to accommodate VMS.
But this diff here illustrates the real problem:
-is( $mm-{INSTALLVENDORMAN1DIR}, File::Spec-catdir('foo','bar'),
+my $expect = File::Spec-catdir('foo','bar');
+$expect = VMS::Filespec::vmspath($expect) if $Is_VMS;
+is( $mm-{INSTALLVENDORMAN1DIR}, $expect,
'installvendorman1dir (in %Config) not modified' );
Now every call to File::Spec, which is supposed to generate a portable path,
has to have extra code tacked onto the end to do more work. If that's
necessary then File::Spec::VMS should be doing it.
In conclusion, this should all be built into File::Spec::VMS.
--
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml
Re: Better way to handle Unix compatibility modes must be found
John E. Malmberg wrote: It is only the case where something is building a VMS specific Make script or building a DCL command file that a filename needs to specifically be converted to VMS path syntax. Ok, then build it into the MakeMaker File::Spec overrides and use them. -- 10. Not allowed to purchase anyone's soul on government time. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Rethinking how ext/ is tested
Nicholas Clark wrote:
On Tue, Mar 03, 2009 at 08:07:04PM -0800, Michael G Schwern wrote:
Craig A. Berry wrote:
On Fri, Feb 27, 2009 at 5:14 PM, demerphq demer...@gmail.com wrote:
2009/2/27 Michael G Schwern schw...@pobox.com:
The plan changed in the middle of this argument and I think that wast
lost. I
no longer plan to do it with make subtests but rather by hacking t/TEST
and
t/harness. It should work out to no visible change. Rather than
untangle the
I like this plan.
I'd been thinking about all this (before reading the rest of the thread) and
had concluded that
a: I'd changed my mind from mmm, more change than I feel comfortable with to
a good idea, as it simplifies things
b: That the right way to do it (at least for t/harness) is to get TAP::Harness
to run everything, and know how to change directory.
I ran into a problem with b. Using exec() I can make TAP::Harness chdir
before running the test, but I can't make it chdir back without using
something funky like an end of scope object. So it would be nice if that were
possible, maybe with the simple expedient of allowing exec() to return a
filehandle instead of a program to run.
Meanwhile, I'm going to put the logic to run a core test into its own little
program. This solves three problems. The one above, because now TH can just
exec it. It removes duplication between TEST and harness. And three, it
makes it easier to run a single test from the command line. Rather than
having to duplicate all the stuff that TEST does, you can just run the little
wrapper script.
The effective change to the testing system is rather small. Here you can see
it without refactorings.
git diff 1a129493906affc7fd0e26067910a344e22fb5f2^..HEAD t/TEST t/TestInit.pm
Is there an easy way in the github UI to let me do the above, without needing
to clone to local disk? Likewise, is there an easy way on the github UI to
get a diff between two forks? (in this case, your branch, and the mirror of
blead)
If its there I haven't found it.
ext/ExtUtils-MakeMaker/lib into lib is incomplete. I'm not sure how that
should best be done. Ideally I'd like make to take care of it so that as
ext/ExtUtils-MakeMaker/lib is edited, it will be copied into lib as
necessary.
I'm not sure on this. The best I could think of was to go from having 3
classes
of extension in the core's Makefile - dynamic, static and non-xs, to 4,
those 3 plus early. early gets built first, before the other 3, and
might just be ext/ExtUtils-MakeMaker, and it would be built with a bonus
-Ilib, ie
cd ext/ExtUtils-MakeMaker
../../miniperl -I../../lib -Ilib Makefile.PL
make
cd ../..
(either one early, and a bonus -Ilib, or 1 for each dir in early
map { -I../../ext/$_/lib } @early;
which wouldn't get out of hand if there aren't that many directories in the
early class)
early would essentially be the configure_requires and build_requires for
any other module in ext.
I'm not sure if that meets your goal of if ext/ExtUtils-MakeMaker/lib is
edited, it will be copied into lib as necessary, but I don't think we have
that right now on anything else in ext/
Aside from ensuring lib/ keeps in sync with ext/ there's another desire.
MakeMaker relies on core modules. Right now things work because it doesn't
rely on anything in ext.. I think. MakeMaker, like most modules, doesn't
spell out its core requirements. But with MakeMaker building itself out of
ext we can rapidly run into a circular dependency problem where MakeMaker
needs something else in ext.
Anything MakeMaker needs has to be cracked up into lib which is counter to the
goal of pulling CPAN distributions back together. Case in point, File::Spec
which is really part of PathTools. It's scattered between lib/ and ext/Cwd.
Very little works without File::Spec.
If instead of having the pumpkings copy PathTools-X.YY/lib/ into lib/ by hand,
or whatever clever script exists to do it, we incorporated it into the build
process so that it copied from ext/PathTools/lib/ then we'd have a generic
system for dealing with this problem not just for MakeMaker but for every dual
life non-xs module that lives in lib.
One way to implement it to have Makefile.SH iterate through the
ext/$non-xs/lib directories and create targets like this:
lib/ExtUtils/MakeMaker.pm: ext/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm
cp ext/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm $@
lib/ExtUtils/MM_Unix.pm: ext/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
cp ext/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix $@
and so on.
--
Ahh email, my old friend. Do you know that revenge is a dish that is best
served cold? And it is very cold on the Internet!
Re: Rethinking how ext/ is tested
Craig A. Berry wrote: On Fri, Feb 27, 2009 at 5:14 PM, demerphq demer...@gmail.com wrote: 2009/2/27 Michael G Schwern schw...@pobox.com: The plan changed in the middle of this argument and I think that wast lost. I no longer plan to do it with make subtests but rather by hacking t/TEST and t/harness. It should work out to no visible change. Rather than untangle the miscommunication in email its simpler and faster for me to just do it and let the code speak for itself. That sounds great! Yes, indeed. Even if the hacks are wicked they'll be corralled into one or two places where we can keep an eye on them. It is done. Or at least, it is demonstratable. http://github.com/schwern/perl/tree/ExtUtils-MakeMaker The effective change to the testing system is rather small. Here you can see it without refactorings. git diff 1a129493906affc7fd0e26067910a344e22fb5f2^..HEAD t/TEST t/TestInit.pm I altered t/TEST to run ext/Module tests from ext/Module. This leaves how tests are run outwardly unchanged. I then stripped all the PERL_CORE path hackery out of the ext/ tests which is what really consumed all the time. I kept changes to a minimum and in separate commits for each module to facilitate pushing them back to the authors. In some cases I moved files out of t/ and back into ext/ when doing so would restore the integrity of a CPAN distribution and eliminate a PERL_CORE hack. t/Module_Pluggable for example. I realize some of the moves were made because of VMS depth limits. I think now that ext has been flattened this should be ok. If not, a better solution might be for TEST to create a VMS virtual root for each ext/Module and chdir into that. I also made the path to perl and the lib directories absolute so tests can chdir safely and added . into @INC so it's more like how perl really runs. One debatable bit is t/TEST's use of File::Spec-rel2abs. TEST was already using File::Spec but now its also using Cwd. Fortunately, Cwd can work as a Perl module. Also, if things go really bad, you can run TEST using an already installed Perl. Even a rather old one should work. t/harness still needs to be dealt with. And the system for copying ext/ExtUtils-MakeMaker/lib into lib is incomplete. I'm not sure how that should best be done. Ideally I'd like make to take care of it so that as ext/ExtUtils-MakeMaker/lib is edited, it will be copied into lib as necessary. -- Schwern What we learned was if you get confused, grab someone and swing them around a few times -- Life's lessons from square dancing
Re: Rethinking how ext/ is tested
Rafael Garcia-Suarez wrote: 2009/2/26 Michael G Schwern schw...@pobox.com: This is annoying and really its unnecessary. The point of putting non-XS modules into ext/ is to reduce the differences between the CPAN and core versions. This goes both ways. The core is currently cheating in how it runs ext/ tests, it's running them manually rather than using make test. So I propose changing how the core runs the ext/ tests. Rather than running them as part of one large run, let's take advantage of make and just let make test cascade down into the ext/ directories. The t/ and lib/ tests would run first, then make test would be run in each ext/ directory. Thoughts? I'm going to go hack on that. We have two test frameworks, t/TEST and t/harness. t/TEST is the simple one, for testing broken things. It has no dependencies. Most notably, if Test::Harness is broken, t/TEST still works. Your proposal implies that t/TEST goes away. t/TEST would still run the t/ and lib/ tests. So all of the tests of core perl functionality are still run with t/TEST. That's all left as is. t/harness is the complex one, but requires Test::Harness to be built and installed in lib/ properly. Your proposal implies that it should be able to collate the results of many sub-runs in each ext/ subdir. Is this handled already ? That doesn't sound like a simple thing to do portably. Oh no, just using normal recursive make. test: perl-test ext-test ext-test: cd ext/Attribute-Handlers $(MAKE) test cd ext/ExtUtils-MakeMaker $(MAKE) test cd ext/Errno $(MAKE) test ...and so on... Each test will show up to the user as an individual test run and result, rather than the huge block of tests we get now. This is visually unappealing, and maybe we can do something to make it a little nicer, but that's how recursive make works everywhere else including MakeMaker. Like anything else in make, if any of the subtest commands fail the whole thing will fail. -- 151. The proper way to report to my Commander is Specialist Schwarz, reporting as ordered, Sir not You can't prove a thing! -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Rethinking how ext/ is tested
demerphq wrote: Id prefer we find a different solution. Im not sure what it is, but having the tests all run in one block is a very desirable feature. What you are saying is that to know what is broken we have to review many test summaries, this sound sensible if you are thinking about tests only being broken in your module, but its not sensible when a core change has broken a nice chunk of the modules out there. You want to be able to look at one summary at the bottom of all the failures. Reviewing a stack of summaries with different counts and etc doesnt sound fun. Eh, we already have to search around in that huge list of test results anyway to get results. It's not like this is going to be much worse. We already deal with a similar issue when building the ext modules. In the case of ext's tests, they're all going to be outputting in the same format to it's not like we're introducing some wild west of tests here. But, like I said, the formatting can probably be improved. We've got a known version of Test::Harness and can play with HARNESS_OPTIONS to transparently tinker with TAP::Harness. If we use the traditional make subtest setup, testing will stop once the first ext module fails. While this would certainly make them easier to find, this is probably not desirable given the Perl tradition of always running all tests. A small wrapper would need to be put in place to ensure all the tests run. The important thing is the core change from running the ext/ tests manually to using each module's own make test. This will make integrating and developing dual life modules far easier by eliminating a key difference in how ext/ and CPAN modules are developed. -- 94. Crucifixes do not ward off officers, and I should not test that. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Rethinking how ext/ is tested
Craig A. Berry wrote:
On Thu, Feb 26, 2009 at 8:32 PM, Michael G Schwern schw...@pobox.com wrote:
Craig A. Berry wrote:
The important thing is the core change from running the ext/ tests
manually to
using each module's own make test. This will make integrating and
developing dual life modules far easier by eliminating a key difference in
how
ext/ and CPAN modules are developed.
Hmm. This only makes any difference for modules that distribute their
own libraries that are only used for testing, right? It looks like
ext/Test-Harness/t/lib is the only one like that currently. Add
Module::Build and ExtUtils::MakeMaker when they get moved to ext/,
maybe a couple others.
It's a general purpose problem that effects all the ext/ modules.
You mean affects, not effects.
Thank you, you have saved the Internet.
Most tests
have some special code to accommodate the duality of core vs CPAN testing.
Usually its just this:
BEGIN {
if ($ENV{'PERL_CORE'}){
chdir 't';
unshift @INC, '../lib';
}
}
But it will effect any test that needs to know its position relative its
source tree, usually to read another file or load a module in the source
tree.
Is that really considered a best practice? I know a lot of smart
people do that, but in my experience, this sort of cleverness often
leads to things going wrong.
Reading a file in a subdir is clever?
CPANPLUS and CPAN are good examples off the top of my head. But it's not
limited to just finding stuff in their own t/lib.
CPANPLUS tests use FindBin to locate themselves and find their
friends. It's not immediately clear the tests would need any changes
to move over to ext/ (though it is big and complicated and can't be
known for sure without trying it).
Right, they do that because it's not clear from where the test will be run so
it needs extra code to figure that out. Using FindBin is a clever technique
that lets the test be moved around, but earlier versions did something more
static:
BEGIN {
if( $ENV{PERL_CORE} ) {
chdir '../lib/CPANPLUS' if -d '../lib/CPANPLUS';
unshift @INC, '../../../lib';
### fix perl location too
$^X = '../../../t/' . $^X;
}
}
And most of the tests are written with kludges like that. Here's one from
lib/CPAN/t/03pkgs.t so it can test that its own modules will load.
my @m;
if ($ENV{PERL_CORE}){
@m = (CPAN, map { CPAN::$_ } qw(Debug
DeferredCode
Distroprefs
FirstTime
Kwalify
Nox
Queue
Tarzip
Version
));
} else {
opendir DH, lib/CPAN or die;
@m = (CPAN, map { CPAN::$_ } grep { s/\.pm$// } readdir DH);
}
MakeMaker's t/00compile.t isn't working in ext/ at the moment because it can't
find its own modules, it's going to need some sort of kludge like that if
things are left as is.
ext/Cwd/t/cwd.t has some typical examples of groping around looking for test
directories:
$want = $ENV{PERL_CORE} ? $Test_Dir : File::Spec-catdir('t', $Test_Dir);
if ($ENV{PERL_CORE}) {
chdir '../ext/Cwd/t';
unshift @INC, '../../../lib';
}
And MakeMaker did some pretty deep back bends to work out the differences.
The more we do this, the more we're going to find exceptions, the more
hacks
we have to put into place and what's going to wind up happening is we're not
going to want to move things into ext. Making ext/ as much like the normal
module process as possible smooths out the transition.
I'll try to keep an open mind and assist where I can, but from where I
sit this is just shifting time and attention away from important
things like fixing known bugs and getting releases out the door toward
putting out all the fires that will inevitably arise from breaking
something that is known to be stable and working.
That's the general purpose excuse for any change. It doesn't fly, volunteers
aren't interchangeable parts. You can't say don't scratch that itch, scratch
this one. I will freely admit I'm doing this because it's been a royal pain
in my ass for years.
I'm going to reverse the advice and instead of continuing to justify this
change I'll just implement it and see whether the sky remains up.
--
But there's no sense crying over every mistake.
You just keep on trying till you run out of cake.
-- Jonathan Coulton, Still Alive
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.49_01
Craig A. Berry wrote: On Sat, Feb 21, 2009 at 4:06 AM, Michael G Schwern schw...@pobox.com wrote: Nicholas Clark wrote: Applied to blead as 1487aac67a72b9f87b24113f65b4d878401bee33 Thanks. There's a new failure on VMS, but this should take care of it: http://rt.cpan.org/Public/Bug/Display.html?id=43511 I'll get that in and your other VMS patches. Thanks. should I be raising RT tickets for these instead? Keep raising RT tickets. Does that mean CPAN is upstream, as in: The CPAN MakeMaker has always been upstream, though by the definition in Maintainers.pl it should probably be set to first-come which is what has been done in practice. Or is MakeMaker too essential to building the core for upstream to really mean anything? And is GitHub the best place to host MakeMaker, or could it be put on git.perl.org and pumpkings given write access for emergencies, like when there is a release coming up but Michael is away from e-mail for awhile. I'm just thinking out loud -- if that involves too much work by too many people, then just pulling from GitHub does look like an improvement over applying patches. The pumpkings have never needed write access to the MakeMaker repository to make changes to their copy in Perl, or even to make an emergency CPAN release. Moving to github doesn't change that. What it does change it making it a whole lot easier to keep in sync with blead, for others to work on MakeMaker and for me to integrate that work. The MakeMaker fork on github is basically working. There's some nits to be ironed out, and I want to change the way the modules in ext/ are tested, but it looks like it's going to work. -- There will be snacks.
Rethinking how ext/ is tested
I've got MakeMaker mostly working sitting in ext/ExtUtils-MakeMaker in the
core. You can see it here.
http://github.com/schwern/perl/tree/ExtUtils-MakeMaker
The logic for copying ext/ExtUtils-MakeMaker/lib into lib/ is primitive and
isn't integrated into make clean, but it's basically correct. MakeMaker is
kind of confused about being in a subdir of the Perl core, so it won't yet
build as a CPAN module, but I know how to fix that.
There's a MakeMaker test that fails because it doesn't expect $^X to be a
relative path and here we hit the snag. In order to normalize how tests are
run between CPAN and the core, each MakeMaker test has to include code like
this:
BEGIN {
if( $ENV{PERL_CORE} ) {
unshift @INC, '../ext/ExtUtils-MakeMaker/t/lib';
}
else {
unshift @INC, 't/lib';
}
}
This is because the core runs tests in its own t/ but doing it CPAN-style
would mean running them in ext/ExtUtils-MakeMaker/ So if I want to include
t/lib in @INC I have to include scaffolding like the above and always remember
that the tests might be running from an odd location.
This is annoying and really its unnecessary. The point of putting non-XS
modules into ext/ is to reduce the differences between the CPAN and core
versions. This goes both ways. The core is currently cheating in how it runs
ext/ tests, it's running them manually rather than using make test.
So I propose changing how the core runs the ext/ tests. Rather than running
them as part of one large run, let's take advantage of make and just let make
test cascade down into the ext/ directories. The t/ and lib/ tests would run
first, then make test would be run in each ext/ directory.
Thoughts? I'm going to go hack on that.
--
Hating the web since 1994.
Moving MakeMaker into git, how to do it?
Once I moved Test::More to github a bunch of people asked if I planned on doing the same with MakeMaker. The answer is yes. The ability for others to fork their own copies and for me to easily pull in changes will be invaluable for MakeMaker. Rather than just put the CPAN module on github, some folks suggested I instead fork the perl repository and work from that. This would make keeping MakeMaker in sync with p5p a whole lot easier. For a normal module the plan would be simple, stick it into ext/ and work from that. But MakeMaker builds everything else and needs some special attention. The key thing being that MakeMaker has to be installed into lib/ before the rest of ext/ can build. I see two strategies: 1) Copy ext/ExtUtils-MakeMaker/lib/ into lib/ at some point early in the build process. 2) Jigger the ext/ build process so MakeMaker gets built first and installed into lib/ I've made a fork on github and copied MakeMaker into ext/ http://github.com/schwern/perl/tree/ExtUtils-MakeMaker Could someone familiar with the Makefile do the necessary voodoo to implement either of the above strategies? -- Look at me talking when there's science to do. When I look out there it makes me glad I'm not you. I've experiments to be run. There is research to be done On the people who are still alive. -- Jonathan Coulton, Still Alive
Re: Moving MakeMaker into git, how to do it?
Rafael Garcia-Suarez wrote: I see two strategies: 1) Copy ext/ExtUtils-MakeMaker/lib/ into lib/ at some point early in the build process. 2) Jigger the ext/ build process so MakeMaker gets built first and installed into lib/ The first option looks more feasible, since the copying into lib is done via Makemaker-generated makefiles anyway. (IIRC) This should be all that is necessary: cp -r ext/ExtUtils-MakeMaker/lib/* lib/ Just need to know where to put it. -- We do what we must because we can. For the good of all of us, Except the ones who are dead. -- Jonathan Coulton, Still Alive
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.49_01
Nicholas Clark wrote: Applied to blead as 1487aac67a72b9f87b24113f65b4d878401bee33 Thanks. I then re-applied the changes from http://rt.perl.org/rt3/Public/Bug/Display.html?id=61492 to blead as 2f30d0d0af5b459d5c0f4734d92d4b55e9dcc9b7 as it seemed to be a fix for a class of build failure: Oh good, that grotty compiler check has been nothing but trouble. I'll apply it. I *didn't* re-apply the part of 4954abf77fcbac122d63699b1b3921b4d44d4570 to blead: *snip* as I think it was this part: This also silences an odd warning from MM_Any.pm that comes up once in a while, which I believe is to do with a deeper core failure as it occurs in code utterly unrelated to these changes. Yeah, I saw that one and decided not to integrate. I prefer *not* to silence warnings until I understand what caused them. So if you see that warning again, let me know so I can diagnose. The docs still say: Send patches and ideas to Cmakemaker@perl.org. should I be raising RT tickets for these instead? Keep raising RT tickets. That's just there for simplicity. Speaking of core coordination, now that we're on git I've been pondering how best to take advantage of that. Because this sort of thing above happens a lot. I'm going to experiment with somehow working with a fork of perl rather than my own repository. I've made a fork on github, do you guys take github pull requests? -- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.49_01
Léon Brocard wrote: =head1 SUBMITTING A PATCH VIA GITHUB ... The orange branch has been pushed to GitHub, so you should now send an email to perl5-port...@perl.org with a description of your changes and the following information: http://github.com/USERNAME/perl/tree/orange g...@github.com:USERNAME/perl.git branch orange I don't get that part. Is that taking the place of a normal github pull request? -- 54. Napalm sticks to kids is *not* a motivational phrase. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: MakeMaker: Strip *.pl extension during install?
Jari Aalto wrote: WriteMakefile ( EXE_FILES = [qw(bin/dyndns.pl)] ); I'm using Perl 5.10.0. Is there any option that could be set to strip the file extensions during install? I'd like to develop the files with: foo.pl So that local searches like find . -name *.pl can run perl -cw. tests. But during install I'd wish they got instaled as plain: /usr/local/bin/foo Likewise for the manual page: without the *.pl No, there's no option to do that. You could hack something together using PL_FILES but I'd recommend against trying to hack it in as mysterious changing filenames are no fun to debug. Your impulse to strip the .pl extension off executables is correct. I suggest you just rename the source files and change your perl finding program to look for #!/usr/bin/perl or to run everything in bin/ that doesn't have an extension. Don't bother trying to hack this up with find + grep, use File::Find. Using Unix find in your tests is non-portable. -- The interface should be as clean as newly fallen snow and its behavior as explicit as Japanese eel porn.
Re: [PATCH] Haiku Port
Haiku is BeOS.
It should use MM_BeOS.
Delete the copy.
Less poetically, MM_Haiku appears to be just a copy of MM_BeOS. Doesn't seem
to be any benefit from a split, so just alter MM.pm so Haiku is recognized as
a BeOS flavor.
--- a/lib/ExtUtils/MM.pm
+++ b/lib/ExtUtils/MM.pm
@@ -58,7 +58,7 @@ if( $^O eq 'MSWin32' ) {
$Is{UWIN} = $^O =~ /^uwin(-nt)?$/;
$Is{Cygwin} = $^O eq 'cygwin';
$Is{NW5}= $Config{osname} eq 'NetWare'; # intentional
-$Is{BeOS} = $^O =~ /beos/i;# XXX should this be that loose?
+$Is{BeOS} = $^O =~ /beos/i or $^O eq 'haiku';
$Is{DOS}= $^O eq 'dos';
if( $Is{NW5} ) {
$^O = 'NetWare';
--
24. Must not tell any officer that I am smarter than they are, especially
if it's true.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: [PATCH] Haiku Port
H.Merijn Brand wrote:
On Wed, 29 Oct 2008 03:09:06 -0700, Michael G Schwern
[EMAIL PROTECTED] wrote:
Haiku is BeOS.
It should use MM_BeOS.
Delete the copy.
Less poetically, MM_Haiku appears to be just a copy of MM_BeOS. Doesn't seem
to be any benefit from a split, so just alter MM.pm so Haiku is recognized as
a BeOS flavor.
--- a/lib/ExtUtils/MM.pm
+++ b/lib/ExtUtils/MM.pm
@@ -58,7 +58,7 @@ if( $^O eq 'MSWin32' ) {
$Is{UWIN} = $^O =~ /^uwin(-nt)?$/;
$Is{Cygwin} = $^O eq 'cygwin';
$Is{NW5}= $Config{osname} eq 'NetWare'; # intentional
-$Is{BeOS} = $^O =~ /beos/i;# XXX should this be that loose?
+$Is{BeOS} = $^O =~ /beos/i or $^O eq 'haiku';
Hmm, I smell precedence error
Thanks.
--
I'm pale as formica, social skills stunted small. But I'm accurate
like a pica, I know the capital of nepal. I'm the nemesis of error,
dreadful diction fears my skills, more inquisitive than Jim Lehrer,
snottier than Beverly Hills.
-- I.L.O.P. Secret Rap http://goats.com/archive/020830.html
[ANNOUNCE] ExtUtils::MakeMaker 6.48
http://search.cpan.org/dist/ExtUtils-MakeMaker The changes since the last stable release are mostly test fixes. There is one new feature, MIN_PERL_VERSION, which lets you specify the minimum perl version required in a more formal way than just putting a use 5.006 in your Makefile.PL. 6.48 Mon Oct 20 11:18:13 PDT 2008 Test Fixes * Protect against stray environment variables effecting the tests. [rt.cpan.org 14930] 6.47_02 Thu Oct 16 16:14:20 PDT 2008 Test Fixes * MIN_PERL_VERSION test had some goofs on VMS. [thanks Craig Berry] 6.47_01 Tue Oct 14 12:38:05 EDT 2008 New Features * Added optional parameter MIN_PERL_VERSION, to define minimal required perl version for dependency checks and to pass on to META.yml and ppd files.[rt.cpan.org 28374] Thanks to David Golden, Alexandr Ciornii (chorny) and Martin Becker Bug Fixes * Guard against a path to Perl with a space in it. From Max Maischein. [EMAIL PROTECTED] Test Fixes - Small fix for VOS from Paul Green [EMAIL PROTECTED] Other * $ExtUtils::MakeMaker::Revision, $ExtUtils::MM_Unix::Revision and $ExtUtils::MM_VMS::Revision are all now based on $VERSION. You shouldn't be using them for anything anyway. 6.46 Sat Sep 27 17:34:03 EDT 2008 Bug Fixes - Fix META_MERGE for more than one level of hashes. [rt.cpan.org 39348] -- We do what we must because we can. For the good of all of us, Except the ones who are dead. -- Jonathan Coulton, Still Alive
Re: ANNOUNCE ExtUtils::MakeMaker 6.47_02
Nicholas Clark wrote: On Thu, Oct 16, 2008 at 04:18:45PM -0700, Michael G Schwern wrote: http://schwern.org/src/ExtUtils-MakeMaker-6.47_02.tar.gz Cutting a new release to fix some VMS issues on the new MIN_PERL_VERSION tests. In blead with change 34498. I noticed that ExtUtils/MM_Darwin.pm doesn't have a $VERSION. Got it, thanks. -- Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
ANNOUNCE ExtUtils::MakeMaker 6.47_02
http://schwern.org/src/ExtUtils-MakeMaker-6.47_02.tar.gz Cutting a new release to fix some VMS issues on the new MIN_PERL_VERSION tests. 6.47_02 Thu Oct 16 16:14:20 PDT 2008 Test Fixes * MIN_PERL_VERSION test had some goofs on VMS. [thanks Craig Berry] 6.47_01 Tue Oct 14 12:38:05 EDT 2008 New Features * Added optional parameter MIN_PERL_VERSION, to define minimal required perl version for dependency checks and to pass on to META.yml and ppd files.[rt.cpan.org 28374] Thanks to David Golden, Alexandr Ciornii (chorny) and Martin Becker Bug Fixes * Guard against a path to Perl with a space in it. From Max Maischein. [EMAIL PROTECTED] Test Fixes - Small fix for VOS from Paul Green [EMAIL PROTECTED] Other * $ExtUtils::MakeMaker::Revision, $ExtUtils::MM_Unix::Revision and $ExtUtils::MM_VMS::Revision are all now based on $VERSION. You shouldn't be using them for anything anyway. 6.46 Sat Sep 27 17:34:03 EDT 2008 Bug Fixes - Fix META_MERGE for more than one level of hashes. [rt.cpan.org 39348] -- 170. Not allowed to defect to OPFOR during training missions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
EXTRA_META is no more!
Just giving notice to those who peeked inside MakeMaker's Makefile.PL and used the never documented EXTRA_META, it's gone from the latest release. The new META_MERGE and META_ADD should be used instead. -- Robrt: People can't win Schwern: No, but they can riot after the game.
[ANNOUNCE] ExtUtils::MakeMaker 6.46
http://schwern.org/src/ExtUtils-MakeMaker-6.46.tar.gz The feature everyone's been asking for, you can finally alter how the META.yml is written. Borrowing from Module::Build, you can now specify META_MERGE and META_ADD in your Makefile.PL to add new values to META.yml. META_MERGE merges the new values with the defaults, META_ADD overwrites. This allows MakeMaker users to take full advantage of META.yml and specify things MakeMaker does not explicitly support, like resources and build_requires. NOTE: EXTRA_META has been REMOVED! It was never documented, anyone using it should switch to using META_MERGE. Finally, the latest META.yml spec is used (1.4). A practical example of use is here: http://search.cpan.org/src/MSCHWERN/Test-Simple-0.81_02/Makefile.PL 6.46 Sat Sep 27 17:34:03 EDT 2008 Bug Fixes - Fix META_MERGE for more than one level of hashes. [rt.cpan.org 39348] 6.45_02 Sun Sep 7 13:59:14 PDT 2008 Bug Fixes - Updated bundled ExtUtils::Command to 1.14, ExtUtils::Install to 1.50 and ExtUtils::Manifest to 1.54 Test Fixes - t/writemakefile_args.t had the wrong skip amoung causing failures when run without version.pm (mostly 5.6 users) 6.45_01 Sat Sep 6 03:19:03 PDT 2008 New Features * META_ADD and META_MERGE have been added to manipulate the META.yml. Thanks to Adriano Ferreira. [rt.cpan.org 21282] - META.yml now includes configure_requires ExtUtils::MakeMaker by default. [rt.cpan.org 32337] - META.yml now excludes t/ and inc/ from indexing by default. - META.yml license is now unknown instead of undef if a LICENSE is not given. - META.yml now conforms to version 1.4 of the spec. Bug Fixes - Make @MM_Sections and @Overridable global again. It's an undocumented but used way to manipulate MakeMaker behavior. [rt.cpan.org 36047] Portability * Changed the name/dmake test in MM_Win32.pm to use regexs to that they are able to handle Perl on a Stick absolute paths. 6.44 Thu Feb 28 16:06:04 PST 2008 Bug Fixes * Updated bundled ExtUtils::Install to 1.45 which should fix some Cygwin issues. [rt.cpan.org 33291] -- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: configuring a script before it is installed
Peter Michaux wrote:
On Wed, Aug 27, 2008 at 6:21 PM, Peter Michaux [EMAIL PROTECTED] wrote:
Hi,
I'm building a command line to-do CPAN module. The module will have
some scripts that need to be installed in /usr/local/bin, for example.
These scripts need to manipulate data files in /usr/local/etc and
/usr/local/var, for example, which contain the application
configuration and database of actual to-dos. I want the
/usr/local/etc and /usr/local/var directories to be configurable
during the perl Makefile.pl; make stage of installing the CPAN
module.
I think that /usr/local/etc and /usr/local/var strings need to be
hard coded into my scripts somehow. Right now I'm using the GNU
./configure; make; make install system and am using m4 macros
@sysconfdir@, @localstatedir@ to modify the scripts (i.e. hard code
the string) before they are installed. I'd like to use the Perl system
(not the GNU system) for building so that my module can be used on all
systems with Perl.
Is what I want to do possible with MakeMaker?
After a bunch of hunting around I discovered that PM_FILTER in
combination with sed seems like it will be able to do what I want
PM_FILTER = 'sed -e [EMAIL PROTECTED]@]%/usr/local/var%g | ' .
'sed -e [EMAIL PROTECTED]@]%/usr/local/etc%g';
If there is something better please let me know.
PM_FILTER will work, but as it's a raw shell command it is inherently
non-portable. If that's not a concern, go with it.
Personally I'd use Perl instead of sed. You know you have Perl.
PM_FILTER
= $^X -i -pe '[EMAIL PROTECTED]@}{$State_Dir}g;.
[EMAIL PROTECTED]@} {$Conf_Dir}g'
Use prompt() to ask the user what their state and config directories should be.
--
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/
Re: perl prerequiste (repost)
Alexandr Ciornii wrote: Hello! This is patch to add support for MIN_PERL_VERSION for Makefile.PL. Used parts of David's patch. Tested with latest version of EUMM on Windows. It yet not adds info to META.yml - that would be second patch. Sorry Alex, I've ignored this too long. Thank you for the good work, I'll do the META.yml bit. -- package Outer::Space; use Test::More tests = 9;
Re: META_MERGE overwrites no_index defaults
Ken Williams wrote: On Wed, Sep 17, 2008 at 4:13 PM, Michael G Schwern [EMAIL PROTECTED] wrote: Hmm, _hash_merge will have to recurse. Is an issue for M::B too? I pulled my hash_merge from MB, so probably. -- Clutter and overload are not an attribute of information, they are failures of design -- Edward Tufte
Re: META_MERGE overwrites no_index defaults
brian d foy wrote: I started playing with the MakeMaker 6.45_02 and ran into a problem with META_MERGE not really merging. I think I've got most of it figured out, but I didn't finish off the fix: http://rt.cpan.org/Ticket/Display.html?id=39348 Hmm, _hash_merge will have to recurse. -- Look at me talking when there's science to do. When I look out there it makes me glad I'm not you. I've experiments to be run. There is research to be done On the people who are still alive. -- Jonathan Coulton, Still Alive
[rt.cpan.org #21282] Split metafile generation into user overridable methods.
URL: http://rt.cpan.org/Ticket/Display.html?id=21282 I've finally patched this in, sorry for taking so long. I took a different route following Module::Build's example. Rather than have users override a method, they can supply META_ADD and META_MERGE, like Module::Build's meta_add and meta_merge attributes, to add/override or merge in more metadata. There shouldn't be any need for overriding the methods. Rather than repurpose EXTRA_META, it's now gone. The work you did on the dumper was splendid. I made a few formatting tweaks to make the key length stuff a bit smarter, it now figures out a good length automatically.
Re: Requiring a Perl version
Alberto Simões wrote: I would like to ask for some advice: in a module, to require some Perl version, should I do that on the Makefile.PL/Build.PL or just add the use keyword with the Perl version on the .pm file? Or both? In case I should do that on Makefile.PL, what is the correct way? Again a 'use' keyword in the Makefile.PL, or is there any other keyword to use withing MakeMaker configuration hash? Just use 5.008 or whatever in a Makefile.PL. For Build.PL you make perl a requirement like a module. Also doesn't hurt to throw in the use line. PS The CPAN testers software should currently detect a test failing because of an our and turn the result into a N/A. -- 3. Not allowed to threaten anyone with black magic. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: Using MAN1PODS
Alberto Simões wrote: My English is not brilliant. But it might help future head-bangs. Don't worry, I can make the English speak gooder. -- 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/
XS help
I have a project to make the functions of a C program available to Perl for
unit testing purposes. A lot of them use structs like so...
typedef struct
{
char *config_file_name;
char *input_file_name;
char *time_str;
int test_mode; /* flag set from command line or config value */
int mail_input;/* flag set from command line */
int debug; /* flag set from command line */
int save; /* flag set from command line */
GHashTable *forw_hash; /* stores email addresses for forward messages */
...and so on...
} options_struct_t
Note the additional complication of the non-standard GHashTable type (from
Gnome).
They pass them into functions to be modified, prototyped like this:
void set_option(
options_struct_t *options,
char *key,
char *val,
);
I'm having difficulty figuring out how best to map this to Perl, both
conceptually and the XS details. If I was making it Perlish I might have an
options object:
$options-set($key, $val);
but I'm hesitant to change the interface so radically, the point is to test
the C code. I'm going with a more literal translation:
my $opts = {};
set_option( $opts, foo = $foo );
set_option( $opts, bar = $bar );
The real issue is how best to translate between the struct and Perl. Using a
hash, like I do above, means I have to translate key element of the struct to
a hash key and back.
void
_hv2options(HV *hash, options_struct_t *options) {
SV ** hash_val;
if( hash_val = hv_fetchs( hash, mail_input, 0 ) )
options-mail_input = SvIV(*hash_val);
if( hash_val = hv_fetchs( hash, input_file_name, 0 ) )
options-input_file_name= SvPV_nolen(*hash_val);
...and so on...
}
void
_options2hv(options_struct_t *options, HV *hash) {
hv_stores(hash, mail_input, newSViv( options-mail_input ));
hv_stores(hash, input_file_name, newSVpv( options-input_file_name, 0 ));
...and so on...
}
As you can imagine, this rapidly gets tiresome. Also I'm a crappy C programmer.
I know there's something to make C structs act like objects, but I'm having
trouble wrapping my head around it. I have this vague feeling that there's a
way to make Perl auto-generate accessors to each struct element but I'm not
sure how.
Any help?
Complicating this problem is that h2xs will not run over this code, it gets
lost in the twisty maze of includes and drags the CPU with it down in a
drunken spiral.
--
125. Two drink limit does not mean two kinds of drinks.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: Detecting a module to be used by Makefile.PL
Alberto Simões wrote:
Adriano Ferreira wrote:
On Tue, Mar 18, 2008 at 12:37 PM, Alberto Simões
[EMAIL PROTECTED] wrote:
Hi
I need to use a non-core, non-standard module on a Makefile.PL.
- I would like to abort Makefile.PL run if it is not installed;
- I would like it to be installed if being run inside CPAN;
Hints?
Very recent versions of CPAN has support for 'configure_requires',
which looks like the right way to do that.
Hmms... that might be a solution when installing the module through
CPAN. But if the user runs Makefile.PL manually she will get a Can't
locate module message.
Not yet the thing I would love.
The Can't locate module message would seem to indicate exactly what's wrong
and clearly suggests what needs to be done to fix it. If they're installing
by hand they're used to resolving dependencies by hand anyway.
If it's not a good enough message, make a better one. Makefile.PL is just a
program. Unlike require dependencies, it's ok to die if you're missing
configuration dependencies because your Makefile.PL would have done that anyway.
my @missing_deps;
for my $module (@configure_dependencies) {
unless( eval qq{require $module} ) {
push @missing_deps, $module
}
}
die Makefile.PL requires @{[ join ',', @missing_deps ]}.\n
if @missing_deps;
--
54. “Napalm sticks to kids” is *not* a motivational phrase.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: Knowing INSTALL_BASE value
Alberto Simões wrote: is there any change on getting the current 'guess' for INSTALL_BASE (the default, or the one supplied by the user on the command line) before running the WriteMakefile function? I smell an X/Y problem. Why do you need to know that? -- Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
Re: Knowing INSTALL_BASE value
Alberto Simões wrote: Michael G Schwern wrote: Alberto Simões wrote: is there any change on getting the current 'guess' for INSTALL_BASE (the default, or the one supplied by the user on the command line) before running the WriteMakefile function? I smell an X/Y problem. Why do you need to know that? Probably I won't need it on Makefile.PL, and need it on another script. There I can probably grep the Makefile and check if there is that variable. There's much better ways to get at that information, but why do you need to know that? -- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: Knowing INSTALL_BASE value
Alberto Simões wrote: I need to edit a C header file and change the... well... prefix :) Shouldn't it let the include path handle that sort of thing? -- Stabbing you in the face so you don't have to.
[ANNOUNCE] ExtUtils::MakeMaker 6.44
This is a release of 6.43_01 with ExtUtils::Install updated to 1.45. http://schwern.org/~schwern/src/ExtUtils-MakeMaker-6.44.tar.gz OS X users will be happy to know the issues with Apple's special tar has been fixed, no more ._Foo files. Win32 pugs developers should note that a long standing issue with long commands has been fixed. MakeMaker will now install on a fresh 5.6. A note to p5p, I haven't incorporated the ABSPERL whitespace patch. I'm afraid it might cause problems. I'm looking into a more general solution for whitespace in paths. Feel free to reapply the bleadperl patches. 6.44 Thu Feb 28 16:06:04 PST 2008 Bug Fixes * Updated bundled ExtUtils::Install to 1.45 which should fix some Cygwin issues. [rt.cpan.org 33291] 6.43_01 Tue Jan 1 16:06:47 PST 2008 Bug Fixes * Change the is this really a Perl core library directory checks to look for strict instead of Exporter. Now that Exporter is on CPAN it can wind up in site_perl. * split_command() will now set aside a little more space for macro expansion. This should help on systems with cramped command line lengths. Specifically, Pugs on Win32. [rt.cpan.org 20145] Installation * MakeMaker would not install if the installed MakeMaker was too old, like on 5.6.1. The installation process was still using the installed MakeMaker in a few places. This has been fixed. [rt.cpan.org 24746] OS X * make dist will no longer bundle up resource fork files (._foo). [rt.cpan.org 29525] Docs * The documentation of VERSION_FROM was recommending vstrings (1.2.3) which have never worked right. * The documentation for the accepted values of LICENSE moved to Module::Build::API. [rt.cpan.org 32020] Tests * The compilation test was testing the installed modules, not the about-to-be-installed. * xs.t would fail if ExtUtils::CBuilder was not installed. Misc * Cleanups brought to you by no more 5.5 compatibility! * MakeMaker is now perlcritic clean at severity level 5... except the really silly ones. * DIE use vars DIE! * Added some resources to the META.yml -- The past has a vote, but not a veto. -- Mordecai M. Kaplan
Re: grep and smart match should warn in void context
Rafael Garcia-Suarez wrote:
-grep(s/^(.*)/-I$1/, @{$perlinc || []});
+map(s/^(.*)/-I$1/, @{$perlinc || []});
Thanks. I tend to fix them with EXPR for LIST unless there's some sort of
compelling need for a block.
--
THIS I COMMAND!
