Re: Wrapper for backwards compatibility
I do *not* think this idea is terrible, and I agree that it's better to
pull this stuff out into a more central location. However, to your primary
question, as a user I think I'd find it a bit confusing if the module's
name started with `ExtUtils::MakeMaker`, which is a well-known package, but
didn't actually live within that package, making it a bit harder to
figure out what to install in order to use it. So I'd vote for naming it
something with a different prefix.
-Ken
On Wed, Mar 24, 2021 at 5:57 PM Pete Houston wrote:
> On Wed, Mar 24, 2021 at 10:22:12PM +0100, Leon Timmermans wrote:
> > It sounds like a terrible idea. Most of all I'm not sure what problem
> > that would solve.
>
> The problem is the boilerplate sitting in every Makefile.PL to ensure it
> is backwards-compatible with older EUMM versions. Not a huge problem I
> grant you but certainly a bunch of repeated code like this which ideally
> would be abstracted away into a single location.
>
> delete $MF{MIN_PERL_VERSION} if $ExtUtils::MakeMaker::VERSION <
> 6.48;
> delete $MF{META_MERGE} if $ExtUtils::MakeMaker::VERSION <
> 6.46;
> delete $MF{LICENSE} if $ExtUtils::MakeMaker::VERSION <
> 6.31;
>
> etc.
>
> > Writing Makefile.PL by hand is painful, that's why most people (who
> > aren't experts) use tools like Dist::Zilla nowadays.
>
> YMMV. I find writing Makefile.PL by hand to be much less painful than
> using Dist::Zilla.
>
> Pete
> --
> Openstrike - improving business through open source
> https://www.openstrike.co.uk/ or call 01722 770036
>
Re: META_MERGE overwrites no_index defaults
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? -Ken
Re: [patch] First batch of whitespace patches (ExtUtils::MakeMaker)
On Aug 26, 2007, at 3:33 PM, Michael G Schwern wrote:
Max Maischein wrote:
How about using
system(LIST)
Alas, need to capture output.
or the list form of backticks instead of interpolating strings to
feed
to the shell.
What list form of backticks?
Module::Build has this helper function:
sub _backticks {
my ($self, @cmd) = @_;
if ($self-have_forkpipe) {
local *FH;
my $pid = open *FH, -|;
if ($pid) {
return wantarray ? FH : join '', FH;
} else {
die Can't execute @cmd: $!\n unless defined $pid;
exec { $cmd[0] } @cmd;
}
} else {
my $cmd = $self-_quote_args(@cmd);
return `$cmd`;
}
}
sub have_forkpipe { 1 }
-Ken
Re: Tags for CPAN modules.
On Jul 9, 2007, at 3:49 PM, Michael G Schwern wrote: Salve J Nilsen wrote: Michael G Schwern wrote: [..] add a tags keyword to META.yml. Have search.cpan.org so something interesting with that extra information. What's the main difference between a tags keyword and the already-existing keywords field found in META.yml since rev 1.1? http://module-build.sourceforge.net/META-spec-current.html#keywords See, that's why I CC things around before I go ahead and do something stupid. Ok, we'll use that. Funny. I, who presumably wrote that document, don't even remember it being there. I was about to chime in and say that when an author provides their own tags for their work, I think of them as keywords. The term tags has a connotation to me of user-generated labeling. For instance, in academic papers, the author (or perhaps even the conference/journal editor) writes the keyword field. I was quite glad to see a few days ago that cpanforum is adding tags. The obvious problem is that it's just one site, and there may not be enough mass in the perl community to support various tag sets at various cpan-related sites. I wonder if there needs to be (at some point down the road) some distributed merging of tags from the various tagging-enabled cpan metadata sites like search.cpan, cpanforum, perldoc, etc. -Ken
Re: EU::MM 'make distclean'
On Sep 2, 2006, at 3:16 PM, Michael G Schwern wrote: Jos I. Boumans wrote: from the term 'make distclean' i'd expect it to return my build directory in to the state the MANIFEST dictates. However, it seems to be actually only *telling* me what is wrong, without actually removing the wrong files: I believe this is intentional behavior. Consider the very common case where you have just developed a new .pm or .t file and not added it to your MANIFEST. You reflexively type make realclean and your work disappears and you are sad. Right - it should only be deleting files it knows it has created, or which the user/author has included in the 'clean' parameter. Note that the docs also say what it does: just a 'realclean' and then 'distcheck'. Reading the documentation, that seems to be the intention as well :( How would i invoke 'make' to clean out everything that's not in the MANIFEST file? Personally I'd just remove the directory and re-extract it from the tarball, like CPAN.pm does. -Ken
Re: Weird problem with version.pm distro on Darwin
On Aug 29, 2006, at 8:24 PM, John Peacock wrote: John Peacock wrote: INST_ARCHLIB = blib/arch INST_SCRIPT = blib/script INST_BIN = blib/bin INST_LIB = blib/lib INST_MAN1DIR = /var/Documentation/man/man1 INST_MAN3DIR = /var/Documentation/man/man3 Never mind! After I pointed out that this was the problem the OP mentioned that this was a Perl that *he* built himself, using this commandline: ./Configure \ -Dfirstmakefile='GNUmakefile' \ ... -Dman1dir='/var/Documentation/man/man1' \ -Dman3dir='/var/Documentation/man/man3' \ -Dsiteman1dir='/var/Documentation/man/man1' \ -Dsiteman3dir='/var/Documentation/man/man3' \ -Dman1ext=1 \ -Dman3ext=3 \ ... I'm going to write this one off as carbon-based error and leave it at that... Could also be some kind of PREFIX error, I don't know why MakeMaker would be putting absolute paths into the Makefile for INST_MAN*DIR if not for some prefixy problem. -Ken
Re: [ANNOUNCE] Module::Build 0.28 - CPAN
On Apr 28, 2006, at 12:46 PM, Yuval Kogman wrote: What about exposing the full Test::Harness output to CPANPLUS and friends? The smoke reports are so unusable I suspect i'm going to add Build.PL to MANIFEST.SKIP and use only the traditional-makefile it generates for my future releases. Yup, we're going to do that for future releases of Module::Build. The CPANPLUS team decided to turn over maintenance of their CPANPLUS::Dist::Build module to us for that specific reason. It's actually not clear yet whether this will require new M::B features or whether it can just be solved with a new CPANPLUS::Dist::Build release. -Ken
Re: [Module::Build] META.yml and platform dependencies.
On Apr 19, 2006, at 1:46 AM, Andreas J. Koenig wrote:
Index: lib/CPAN.pm
===
--- lib/CPAN.pm (revision 717)
+++ lib/CPAN.pm (working copy)
@@ -5378,6 +5378,11 @@
$CPAN::Frontend-mywarn(Error while parsing META.yml:
$@);
return;
}
+if (not exists $self-{yaml_content}{dynamic_content}
+or $self-{yaml_content}{dynamic_content}
+ ) {
+$self-{yaml_content} = undef;
+}
}
s/content/config/g;
Just a reminder, in case you missed it earlier in the discussion,
that once the Build.PL script gets run, there's a file _build/prereqs
that will dependably list the prereqs, including responses to any
user questions, probing of the system, etc.
-Ken
Re: [Module::Build] META.yml and platform dependencies.
On Apr 13, 2006, at 1:40 AM, demerphq wrote: Seems like if the META.yml creation occured on the installers machine instead of on the distributors machine the problem would go away, and allow inifinte flexibility. So for the time being it looks like I have to hand hack my MakeMaker or something. Hmm. That won't work. CPAN is looking at the META.yml file before running *anything*, including your MakeMaker code. Also, there's already a file called _blib/prereqs that's written while running the Build.PL script, and will contain any dynamically specified prereqs. I did bring up this issue with Andreas when he was proposing the META.yml-reading behavior for CPAN, but he figured he's cross that bridge when we came to it. I think we've come to it? -Ken
Re: [Module::Build] META.yml and platform dependencies.
Hi Yves, This is a known shortcoming of CPAN's approach to dependency detection. There's no solution inside the META.yml itself, though in some distant future version we'd like to expand the little language that describes dependencies so it would indeed be capable of expressing platform-specific dependencies. In the meantime, I'm not sure what to suggest - if you omit the META.yml I assume CPAN would try another method, but I'm not sure. It's also possible that if you put dynamic_config = 1 in the META.yml it could try another method, but I'm certainly not sure about that either. :-/ -Ken On Apr 12, 2006, at 12:36 PM, demerphq wrote: I have a problem with META.yml generation and platform dependencies. It looks to me like CPAN is using META.yml to resolve dependencies instead of letting Build.PL or Makefile.PL handle it. But there doesnt appear to be a way to express that in a METAL.yml. So when i do a build/make dist I end up with a METAL.yml that specifies a win32 specific dependency, and when people on other OSes try to build they try to grab a win32 specifc module. Before I hack whatever it is that generates the META.yml to handle this im wondering if there is anything better to be done? What happens if a package doesnt contain a META.yml? I also think it raises an interesting question. How to express dynamic dependencies in a form like META.yml? It seems to me only in a limited fashion.
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 17, 2006, at 8:01 AM, Nicholas Clark wrote: It won't hurt them, but it will cause immense pain for anyone wanting to ship a module that uses a Build.PL - those developers will be forced to decide whether to cut out anyone with an old Module::Build, or code their Build.PL to use that version and work around the deficiencies. Those authors should just be able to put a 'build_requires' dependency on the right version of Module::Build. The thread on what YAML version Module::Build needs, and how to upgrade correctly if there isn't =0.50 suggests that solving these Module::Build needs upgrading issues isn't yet battle tested. That's a different issue - the problem there is how to handle increases in 'feature' requirements, e.g. the 'yaml_support' feature for M::B. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 8:44 AM, John Peacock wrote: demerphq wrote: cherry picking through your message There is no excuse for a module built with MB going on CPAN without a Makefile.PL. I agree 100%. I'm using using Module::Starter::PBP and (more importantly) Module::Release, so I don't have an option. I actually have a custom version of Module::Release that understands M::B and does a few more things to make my life easier (like looking up my CPAN password in my OS X keychain), but my several attempts at getting patches accepted for it have gone unresponded-to, so I've given up on getting it integrated. I'll mail it to you if you want, though. -Ken
Re: [Module::Build] Re: Summary was: Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker
Hi, This summary, like any summary, is most appreciated. It helps me to clarify where I see things differently, though I agree with some of what's being said here. On 2/16/06, Tels [EMAIL PROTECTED] wrote: For any module, especially the ones for installing other modules (e.g. M::B, EUMM, M::I and CPAN) there are three (not nec. distinctive) crowds: * A - the original source code author and maintainer.[0] * D - developers, e.g. other people who want (or must, via dependencies) use the module in their code. Often includes A, too. * U - mere users, who just want (or must, see above) to _use_ the module's functionality. Can also include A and D. Fact of the Day: Any module which wants to replace the current build system (EUMM) must please[8] all three crowds or it will fail.[1] M::B is of course trying to please all three of A, D, and U. I had hoped that would be obvious, but in case it's not, I'm re-stating it. Pleasing U does, among other things, require to solve the chicken-egg problem. Well, M::B is a chicken which knows how to lay itself as an egg. And CPAN and CPANPLUS or whatever tool know how to install M::B because it ships with both a Build.PL and a Makefile.PL and has since nearly day one. So at the top of the dependency tree there's a terminus. The issue is thus reduced to making sure other distributions can declare their dependency on M::B in a way that the tools will recognize. M::B::Compat is our current solution for this. It generates three different kinds of Makefile.PLs for authors to include with their distributions. We've put a lot of work into them, which should be Exhibit A for showing that we care about such users. I'm sure we can improve our tools, but I do want to make it clear that they exist and have since April of 2002. What Module::Build claims is that it pleases A and D. From that is infered that U will also be automatically pleased. I have never ever made such an assertion. I do understand that there are issues U considers critical that A and D don't really care much about (unless they're wearing their U hats). Also, we do indeed try to please U in M::B. Witness for example the 'diff' action, and the fact that a huge motivator for the entire project for me is to be able to generate *good* rpms/debs/ppms/etc for any M::B-using CPAN module. There's an immense infrastructure necessary to do that well, and probably A and D will never care about it at all. Who is making such an inference, anyway? So, we have critism from U about not being pleased (Adam writes about this, for instance). To this there are responses along the lines: * U might be displeased or not, but D is very pleased[4]: http://tinyurl.com/du7yc Bzzzt. Wrong answer. It's here that you lose me. I don't know if Bzzzt. Wrong answer and the advocacy in the rest of the message is really summary fodder. Anyway, we've identified some things about the Makefile.PLs that can be improved. We'll do so. Specific issues we can fix, or at least identify, are great. But I resent some of the implications going around that our whole philosophy of the project is wrong, or that somehow we're evil for wanting to create and release a better build system. These things are complicated, and if some area is substandard that's because it needs tuits, not because we don't care about our users. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 3:34 AM, demerphq wrote: The reasons these discussions happen in other venues besides the MB lists is because the MB lists are moderated and sometimes a post doesnt hit the list for days after it was posted and then isnt responded to for some time. Also, I think that expecting every critical thought about MB to be sent to the lists is unrealistic. People have posted lots of discussion on Perlmonks for instance, but ive rarely/never seen you comment. That's true. I don't typically have time to scan perlmonks. Perlmonks is a great site, but for getting things changed in a module or asking questions about rationale, nothing beats contacting the module's authors and/or posting to its mailing list. Is it so hard to pop by a site where your users congregate and see what they are saying about your stuff? Yes. Not only that but when legitimate concerns have been raised the response has been less than positive. For instance the subject matter of this thread (CPAN distros without Makefile.PL's) has been raised time and time again. With almost every time the exact same message. And we still don't see that Makefile.PL being made mandatory. (And judging from your comments in this thread it seems we shouldnt expect to either.) As I understand it, the reasoning is basically there are non-compliant distros on CPAN - so we must MAKE them comply! I'm sorry, but I just disagree. I believe we should *help* them comply. How long did it take to come up with a patch to make Cwd install ok on Win32? A long time and in the end I wrote it. As soon as you realized that MB couldnt install CWD on win32 you should have a) ditched MB for that project until it worked everywhere, b) fixed MB. I mean seriously, if the author of a project like MB can't get it to work properly on his flagship core distro and leaves it as such doesnt it strike you as a pretty serious issue? You want the PathTools distro? You can have it. I only took it because nobody else would. It's a horrible legacy mess and political mess and I would be glad to be rid of it. Why didn't I make Cwd install ok on Win32 sooner? Because I don't have an appropriate Win32 machine to test on, I don't understand ANY of the issues that were going on in that bug, and I don't own the code (ExtUtils::Install) that was determined to need the patching. But you know all this, so why are you flaming me about it? BTW, i really hope that this isnt perceived as a flame. Thats not whats its intended to do. Its intended to be thoughtful and constructive critcism with the aim of improving the standing of MB in the community. I hope it acheives its goal. Not really, it still felt like a flame to me. But whatever, I can ignore the tone and try to just see the points. ps: I'll go out on a limb here and say that MB should NOT be made core until it makes Makefile.PL production mandatory. And until it can install all of the core modules that are built with it on all of the main OS'es that use it. Actually id go even further and say that no core distro should use MB until that distro can be installed on all the main OS'es. You mean no core distro should use *just* M::B, right? I see no harm in having both a traditional Makefile.PL and a Build.PL to give users the choice, do you? In any case, on this Makefile.PL issue: I'm willing to put in an admonition to authors and a y/n button when they try to make a distribution without a Makefile.PL. I think at least 90% of those cases are probably just accidents. But I'm not willing to *force* the author to include a Makefile.PL, whatever force would mean here. Given that, which is on the surface in conflict with your other desire to get 0.28 released ASAP, would you vote for a) getting this into 0.28, or b) waiting until afterwards? -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 1:16 PM, Tyler MacDonald wrote: Ken Williams [EMAIL PROTECTED] wrote: If we did that, we'd screw over people who are already maintaining their Makefile.PL separately by hand. OK... but if they are doing that, the Makefile.PL will be in their *build* directory already... as far as I understand, our Makefile.PL only needs to be generated in the *dist* directory. Yeah, that's true. Let me reconsider my reasoning here from scratch. The original point that Adam Yves were making, IIUIC, was that distributions should include a Makefile.PL. If they don't have one at all, then of course we don't need to worry about clobbering one! So I'd be fine with changing the default in this case to provide some flavor of Makefile.PL generated in the dist directory. The main question would be what style to make it. 'traditional' is accessible by more people, but will often be broken (if, e.g., there are config questions or auto-sensing in the Build.PL they'll be lost to the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough' for this case. That should make most people happy, no? -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 11:45 AM, Tyler MacDonald wrote: I think passthrough is the way to go here. I also still think that if we default in some way to generating a Makefile.PL, create_makefile_pl should be extended to have an explicit skip option as well. Definitely. I'd just change the default to 'auto' (which means create a 'small' [or 'passthrough'] Makefile.PL if none already exists) though, and then the author can explicitly put create_makefile_pl = 0 (or any other false value) in their Build.PL to shut it off. If in the future we figure out how to auto-sense when we could create a 'traditional' Makefile.PL that would be cool, but I don't really see it happening. Too hard. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 2:05 PM, Chris Dolan wrote: Attached below is a regexp-based solution that matches simple Build.PL files. I submit this just for thought, not necessarily for inclusion in M::B. Cool. I wonder if Randy Sims (when he gets back from vacation) could run this against his mini-cpan area to get some statistics on the broader CPAN. Or anyone else, if they're so inclined, certainly. Perhaps this mode could be triggered by Ccreate_makefile_pl = 'automatic' Yeah. As long as we're very strict in how we parse, i.e. any syntax errors according to our grammar for simple Build.PL files are fatal, this does seem like a good way to do things. I would initially like to roll out the 'auto' default without any of this sensing on the Build.PL, but it's going to be good to have in our back pocket. Thanks. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 16, 2006, at 3:48 PM, demerphq wrote: In general yes. But I think its worth considering that traditional is preferable. This http://perlmonks.org/index.pl?node_id=458282 argues that the traditional provides more flexibility for the end user. Yes. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm,and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 15, 2006, at 8:19 PM, Adam Kennedy wrote: But now I'm just getting annoyed and I doubt I can contribute any further to this conversation without repeating myself or resorting to outright flaming, so I'll step out here. Why do you think these threads keep happening on lists that AREN'T M::B's list? It's very frustrating for me. If there are problems we can solve in M::B, please bring them to our attention. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 12:10 PM, John Peacock wrote: I would certainly accept a mandatory warning during './Build dist' if there was no Makefile.PL present, but I think that assuming that everyone wants to release to CPAN is grossly inappropriate. Yes, I was going to make that point too but I forgot. CPAN isn't the whole world. I personally have released modules to CPAN lacking a Makefile.PL, but mostly because I forgot to add one (and since I now try to use Module::Starter::PBP, that isn't going to happen again). I strongly support any author who wants to include only a Build.PL because they don't care if people who refuse to upgrade their core modules get burned. ;-) I agree on the personal rights aspect here. =) I'd still recommend that people include a Makefile.PL, but we can't force it. That would just mean people would have to find creative method to break the enforcement if they really know what they're doing. -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 12:36 PM, Tyler MacDonald wrote: Could create_makefile_pl = passthrough Become the default, and a new option, create_makefile_pl = skip be created to satisfy those who wish to screw over legacy users? :) If we did that, we'd screw over people who are already maintaining their Makefile.PL separately by hand. Not everybody has as many modules to maintain as we do, Tyler. =) -Ken
Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1
On Feb 14, 2006, at 5:43 AM, demerphq wrote: On 2/14/06, Adam Kennedy [EMAIL PROTECTED] wrote: Yitzchak Scott-Thoennes wrote: On Sun, Feb 12, 2006 at 09:26:06PM -0800, Randal L. Schwartz wrote: chromatic == chromatic [EMAIL PROTECTED] writes: chromatic On Sunday 12 February 2006 18:32, Randal L. Schwartz wrote: My prefer_installer is EUMM. And the value of mbuild_install_arg shouldn't matter, because it should always be using EUMM, not MB. chromatic That's going to be difficult for distributions that only provide a Build.PL chromatic file. I recognize that, but (a) those distros should not exist, so that's A couple of months ago I would have agreed. Now I'm not so sure. If you'd care to take time, I'd be interested in hearing your views on what level of MB support would be necessary before such distros should exist. For me it comes down to one simple structural problem (I consider things like PREFIX nigglies that can be fixed). Module::Build (specifically ONLY dists without a Makefile.PL) simply doesn't bootstrap. I think I'm coming into this discussion late. =( What do you mean by doesn't bootstrap? M::B does indeed use itself to install itself, so you must have something else in mind. Could you elaborate briefly to bring me up to date on this discussion? At the very least the Makefile.pl could create a tiny makefile that then runs Build.pl and Build as needed. If someone can explain why this is impossible, then id like to hear it. We already do that, using the 'passthrough' or 'small' options for auto-creating a Makefile.PL. See the docs for Module::Build::Compat. Module::Build itself also ships with such a Makefile.PL so that automated tools like CPAN(PLUS) can install it. -Ken
Re: Sorry, PREFIX is not supported.
On Feb 6, 2006, at 3:01 PM, Bill Moseley wrote: How do I setup CPAN.pm to work with both MakeMaker and Module::Build? I want to install *all* modules locally using CPAN.pm. 'makepl_arg' = q[INSTALLDIRS=site PREFIX=/home/moseley/local], You have a couple options here if you install recent-enough versions of M::B and/or MakeMaker. The recent betas of M::B support --prefix, which is the same as MakeMaker's PREFIX, and the latest versions (betas?) of MakeMaker support INSTALL_BASE, which is the same as M::B's --install_base. Yet, if I use: 'makepl_arg' = q[INSTALLDIRS=site install_base=/home/moseley/local], Then installs fail due to bin not being based on the install_base. I'm not sure I understand this - could you elaborate on how it fails? Is this using Module::Build or using MakeMaker? -Ken
Re: [PATCH] Re: replacing inuse Win files (was Re: Help with aCwd.pm build error)
On Feb 3, 2006, at 3:04 AM, demerphq wrote: If needed Ill volunteer take over maintenance of this (my cpan id is YVES) with Max (cpanid:CORION) as co-maintainer on the *nixy side. I've cc'ed him on this mail. We'd be happy if other maintainers were added I should think, especially if they were handling VMS. :-) There was also someone else who stepped forward at some point (or maybe everyone else stepped back) to take it over a few months ago, but I guess it hasn't happened and I'll be danged if I can't remember who it was. Schwern, you remember? -Ken
Re: [PATCH] Re: replacing inuse Win files (was Re: Help with aCwd.pm build error)
On Feb 1, 2006, at 11:09 PM, Randy W. Sims wrote: If Schwern will give the nod, Ken, do you want to add this to the MB project? Or anyone else interested in maintainership? I'd be happy to host it in M::B's space, but I'm afraid I can donate approximately zero tuits to helping maintain it. -Ken
Re: make -j2 disttest fails
On Dec 26, 2005, at 12:25 PM, Steve Peters wrote: This problems seems to be related solely to BSD-based makes and not GNU make. On my OpenBSD system, make -j2 disttest fails with the default make, but works fine with a GNU make. From my quick and dirty test, it appears that the cd's in a GNU make are in effect for the current command, but you are implicitly returned to your start directory after the completed command. BSD doesn't return you back to your starting directory. Looking at the OpenBSD make(1) manpage, I got a hint to the fix. -j max_jobs Specify the maximum number of jobs that make may have running at any one time. Turns compatibility mode off, unless the -B flag is also specified. So, after running make -j2 -B disttest everything compiled just fine. Check the FreeBSD make manpage to see if there is a similar -B flag. That might be the fix you're looking for. Or if we wanted to make a change in MakeMaker so that it could work with just make -j2 everywhere, maybe something like this would work: disttest : distdir cd $(DISTVNAME) $(ABSPERLRUN) Makefile.PL cd $(ORIGDIR) cd $(DISTVNAME) $(MAKE) $(PASTHRU) cd $(ORIGDIR) cd $(DISTVNAME) $(MAKE) test $(PASTHRU)cd $(ORIGDIR) for some suitable value of $(ORIGDIR). -Ken
Re: [Module::Build] Re: make2build-0.19_01 released
On Oct 14, 2005, at 7:57 PM, Michael G Schwern wrote: I would recommend a change in the way it works. Rather than spitting out a new Build.PL with static entries, the Build.PL should look something like this: # This does the trick of overriding WriteMakefile use Module::Build::Compat::Make2Build; do './Makefile.PL'; That would be fine for someone who wants to maintain the Makefile.PL as their primary builder script and have the Build.PL be subservient to it, but I think the main use for make2build will be for people who want to *switch* from MakeMaker to M::B. If they ended up with a do './Makefile.PL'; as their Build.PL, they'd have little (nothing?) to gain from making the conversion. The main problem with the override WriteMakefile trick is that it runs all the code intended for the user's machine on the *author's* machine, effectively freezing everything that should be dynamic. This works fine for simple modules, but fails (silently!) on something as simple as using a variable in the call to WriteMakefile(). I do still fantasize about a script that actually parses the Makefile.PL rather than using the override WriteMakefile trick. The trick seems like it would get you 100% there for 20% of the Makefile.PLs, silently fail on 70%, and die on 10%. Parsing seems like it could get you 100% there on maybe 60% of them and die on 40%. These are of course very scientifically derived guesses. ;-) Steven, you might be interested to have a look at the makefile_to_build_args() method in Module::Build::Compat as another source of parameter translation. You can call it as a class method if you want. -Ken
Re: [Module::Build] Solving the common-MANIFEST.SKIP entries problem
On Sep 27, 2005, at 11:30 PM, Michael G Schwern wrote: Aside from forgetting to CC [EMAIL PROTECTED] :P Holster that tongue, young man, and get out the hot pokers - not only did I forget to CC the MakeMaker world, I was considering removing all dependence on EU::Manifest entirely. Splitting it out from MM is a better idea, though. Hmmm. Throw in a way to include the default MANIFEST.SKIP and you'll have yourself a winner. If thedefault M.S changes, though, I wouldn't want to auto-update. Too much potential for hey, where did my files go?. -Ken
Re: [Module::Build] Solving the common-MANIFEST.SKIP entries problem
On Sep 28, 2005, at 1:41 PM, Michael G Schwern wrote: I *really* want to get them kicked out of MakeMaker before folks start to fork. Its just... tricky. Fortunately the latest alpha has the necessary tricks to make this possible. Randy Kobes has stepped forward to take both ExtUtils::Command and ExtUtils::Manifest and we're figuring out how to hand off and coordinate releases. Awesome. Thanks, RK. -Ken
Re: [Module::Build] Re: installbase EU::MM and M::B compatibility woes
On Jul 14, 2005, at 4:57 PM, Michael G Schwern wrote: On Thu, Jul 14, 2005 at 12:58:38PM -0700, Yitzchak Scott-Thoennes wrote: Also, EU::MM installs stuff into lib/perl5 (under your selected directory), while M::B uses just lib. Perhaps there's something I'm missing here... This is a bug in Module::Build. It should be fixed in Module::Build 0.27. We've gotta get the 0.27 release out the door. I'm going to just arbitrarily release 0.27_02 now, even though it probably hasn't been fully tested. It is a beta, after all. And I think we need to do more frequent betas if we're going to get 0.28 released sometime before the next ice age. -Ken
Re: [Module::Build] Re: E::MM changes that M::B will benefit of (was: proposal: Module::Build extension...)
On Apr 9, 2005, at 10:03 PM, Michael G Schwern wrote: * split out the auxillary modules (ExtUtils::Install, etc...) from MakeMaker so MB can use/upgrade them without an MM dependency. This depends on Module::Install so... It does? I hadn't realized that - is it because of some chicken/egg problem? -Ken
Re: [Module::Build] distclean misnamed?
On Apr 4, 2005, at 11:34 AM, Michael G Schwern wrote: For reference, this discussion started when Jos was looking for a MakeMaker target which deletes everything not in the MANIFEST. I would never ever ever ever ever ever ever ever want that. One could have distclean move the files to some unclean/ directory instead of deleting them, or confirm before deleting, but really the point of distclean is to make sure that realclean does in fact clean out the distribution back to a pristine state. I guess so. I was never really sure what it was for, I simply accepted a patch that added it along with some other MM actions I never use. I figured the worst that could happen is that a lot of other people won't use them either. I certainly never assumed it was supposed to clean out your distribution for you, though. This brings to mind the people who try to clean out their brains with power drills, or their intestines with long bits of cloth - likely does more damage than good. To that end, maybe distclean is misnamed. I guess it depends on how you read it. If you read it as clean the dist or make the dist clean, then yeah. But there's already a clean and realclean action for doing that. I'm not sure I can offer an alternate reading that makes any more sense though, so yeah, I guess it's misnamed. Personally, I just have my upload tools do an ExtUtils::Manifest::filecheck() before uploading. -Ken
Re: Last call for MM issues prior to 6.26
On Mar 20, 2005, at 2:08 PM, Yitzchak Scott-Thoennes wrote: On Sun, Mar 20, 2005 at 12:30:01AM -0800, Michael G Schwern wrote: On Sat, Mar 19, 2005 at 10:51:39PM -0800, Yitzchak Scott-Thoennes wrote: I was a little surprised to see t/xs reporting No compiler found to test XS builds, till I saw that it is checking for Extutils::CBuilder. Could that be added to build_recommends (or whatever the appropriate tag is) in META.yml? There is no equivalent in MakeMaker. And you can't hand-alter the META.yml? Putting it in the META.yml doesn't really do anything - that's a client-readable file full of meta-information that can be helpful to clients (e.g. CPAN.pm, or search.cpan.org, or a person browsing through an untarred module). It's not actually used during the build process, it's just generated during the 'dist' action. -Ken
Re: Last call for MM issues prior to 6.26
On Mar 20, 2005, at 4:09 PM, Yitzchak Scott-Thoennes wrote:
I was thinking along the lines of:
if (have_compiler($errmsg)) {
plan tests = 1;
} else {
plan skip_all = $errmsg;
}
sub have_compiler {
my $errmsg = ;
...
$_[0] = $errmsg if @_;
return $have_compiler;
}
It would probably be better to set $@ or another global. Using
inout-style arguments is a little unexpected these days unless the arg
is a reference to a data structure.
-Ken
Re: Last call for MM issues prior to 6.26
On Mar 21, 2005, at 12:02 PM, Yitzchak Scott-Thoennes wrote: I'm a client too. I don't use CPAN or CPANPLUS usually to build things, I manually check for dependencies. I dislike it when a module that has dependencies (even just for tests) doesn't mention them in Makefile, META.yml, or a README or INSTALL. Ah, I see. Yeah, for people like you (and for general correctness of the META.yml) it would be nice to add it to the build_requires entry. Or really, since it's not *required*, it should be added to a build_recommends entry. -Ken
Re: Last call for MM issues prior to 6.26
On Mar 21, 2005, at 11:58 AM, Yitzchak Scott-Thoennes wrote: An alternative would be to have have_compiler return ($have_compiler, $errmsg) if wantarray. That makes the code in the caller more clunky though (IMO). Another alternative would be to rename the thing no_compiler, returning undef or an explanation. But I'm not going to pursue these alternatives unless someone likes them better. Or throw an exception, maybe. -Ken
Re: ExtUtils::CBuilder on VMS (was Re: Phalanxing MakeMaker)
On Mar 14, 2005, at 3:55 PM, [EMAIL PROTECTED] wrote: Hmm - well I suppose I should mention a few tricky aspects of using MCR on VMS. [snip] Thanks for letting me know. I'll make sure I'm careful with it. =) I released a non-beta version of ExtUtils::CBuilder that should contain all the patches necessary for VMS workitude. Thanks for your help with it. -Ken
Re: ExtUtils::CBuilder on VMS (was Re: Phalanxing MakeMaker)
On Mar 14, 2005, at 1:30 PM, [EMAIL PROTECTED] wrote: OK that one is much close to what I thought you were aiming at :-) It turns out there was an override typo in VMS.pm and t/02-link.t was left as is. Oops! That was me forgetting to apply the 02-link.t part of the patch. This time around I have checked the return $STATUS of the compilet program in a vmsish fashion, that was done so as not to hurt the successful run on Solaris (where vmsish.pm is not installed and this might be considered a bug in the installperl script that ships with perl). Here is a patch against 0.09_02 that addresses both issues and passes both tests on VMS + perl 5.8.1 and Solaris + perl 5.6.1: Thanks, applied verbatim (except that I moved the system() call into a my_system() subroutine in case I want to use it again later). -Ken
Re: ExtUtils::CBuilder on VMS (was Re: Phalanxing MakeMaker)
On Mar 12, 2005, at 7:18 PM, Ken Williams wrote:
Excellent. I just have one question, then, about the following line:
my @lddlflags = $args{lddl} ? ($cf-{lddlflags}.=$out) :
(/exe=$out);
What is the original value of $cf-{lddlflags} such that it makes
sense to just append =$out to it?
Scratch that, I think I see how it works.
Care to try the 0.09_02 revision, hitting CPAN now?
-Ken
Re: ExtUtils::CBuilder on VMS (was Re: Phalanxing MakeMaker)
Any takers on this? Ping? -Ken On Mar 6, 2005, at 9:50 AM, Ken Williams wrote: On Mar 4, 2005, at 6:39 PM, [EMAIL PROTECTED] wrote: Yes the -foo switches have caused trouble. [snip] Er, sorry at this time I do not have a patch :-) Care to try 0.09_01, which is now hitting CPAN? I've split out the generation of command-line switches so it can easily be overridden for VMS. So compile() might work now. link() and friends haven't been touched, though. -Ken
Re: Phalanxing MakeMaker
On Mar 4, 2005, at 4:07 PM, Michael G Schwern wrote: On Thu, Feb 24, 2005 at 11:47:31AM -0600, Ken Williams wrote: Better would be to snark it from ExtUtils::CBuilder, which has a has_compiler() method. How portable is this? I see there's some minimal VMS and OS/2 code in there, will it work? It should work. Though I've never actually *seen* a VMS or OS/2 machine, so I'm not actually sure they exist. All the cpantesters reports are pretty peachy, but there really aren't many exotic platforms there: http://testers.cpan.org/show/ExtUtils-CBuilder.html#ExtUtils-CBuilder -0.09 If it doesn't work on all platforms, those are bugs that need to be fixed. -Ken
Re: Phalanxing MakeMaker
On Feb 23, 2005, at 6:08 PM, Michael G Schwern wrote: For any brave Phalanx folks who wish to target MakeMaker I can point you at some critically deficient areas of its testing. 1) XS. There is absolutely no testing of XS code. The primary problem is determining if the user has a working build chain. I think Module::Build has code to do this and it might be possible to crib from that. Even just writing the build chain detection code would prove a big help. Better would be to snark it from ExtUtils::CBuilder, which has a has_compiler() method. One could also look at ExtUtils::ParseXS, which is simply a modularization of xsubpp. -Ken
Re: PL_FILES
On Feb 13, 2005, at 6:11 PM, Sisyphus wrote: I know that PL_FILES get processed during the running of 'make' - but is there any documentation that tells me anything about precisely *when* the processing occurs ? - and what triggers the processing of them ? - or how to control the timing of the processing of them ? I imagined they'd all get done together (ie one after the other) but that's not happening. If the info's not sitting around somewhere, then it doesn't matter greatly - this is not something that has to be solved yesterday. I can play around with it and hopefully make it less messy - maybe I'll even learn enough to ask an intelligent question :-) My understanding is that MakeMaker writes a Makefile with all the dependencies, and then make/dmake/nmake work out *when* to satisfy those dependencies. So your question is, in a sense, beyond the scope of MakeMaker. To track this down, try putting the excerpt you quoted into a new Makefile, define the macros it needs, and run it. Does it create the correct output files? -Ken
Re: PL_FILES and EU::MM 6.25_01+
On Jan 8, 2005, at 1:59 PM, Mike Castle wrote: It looks like, starting with 6.25_01, the makefile fragment for PL_FILES has changed. It is no longer passing the target as an option the to PERLRUNINST call. Is this intentional? I didn't see any mention of this in the Changes file. I vote bug. Want to submit a patch? -Ken
Re: Static perl binary for PM module
On Feb 3, 2005, at 10:56 AM, Gustavo Garcia wrote: I thouth that compiling a new static perl, it won't need that the module be install anywhere (it must be included in the binary perl), rigth?. Nope - the perl portion of the module (*.pm) must still be present. The XS or C portion of the module is what's statically linked in with the new perl binary. If you want a way to bundle up an executable that includes all modules, check out PAR: http://search.cpan.org/~autrijus/PAR-0.87/ -Ken
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_03
On Dec 24, 2004, at 1:52 PM, Michael G Schwern wrote: The moral of the story? Directory targets in Makefiles are a bad idea after all. Argh. So, god help me, I may have to return to .exists files. Couldn't you just 'touch' the directories? Or is that not portably easy? -Ken
Re: Change to META.yml and SIGNATURE generation.
On Dec 16, 2004, at 9:13 PM, Michael G Schwern wrote: So at Autrijus' suggestion I have altered the behavior of MakeMaker so that the META.yml and SIGNATURE files will be generated inside the distdir directory. Also they will be added to the MANIFEST file inside the distdir directory, not the source directory. Yeah, that's how Module::Build does it too. -Ken
Re: perl Makefile.PL INSTALL_BASE=~
On Nov 19, 2004, at 4:26 PM, Michael G Schwern wrote: A simpler, and faster to implement, alternative is to go the other way around. Have MakeMaker emulate MB's install_base functionality. Its also saner and less prone to bugs than PREFIX. That's not a bad idea. Sounds good to me. (Not bad == good). -Ken
Re: efficient module version checking without loading the module?
On Mar 25, 2004, at 3:06 PM, David Nicol wrote:
Question: How many ways are there to modify the include-path and
does tainting allow you to set the include-path with tainted
data in any of them and if so can this be repaired?
Without taint checking, the current working directory and
$ENV{PERL5LIB} are both put into @INC. Either of these is suspect.
When taint checking is on, neither is added. So I think the only
directories in @INC that's not compiled into the perl binary will come
from -I switches on the command line (or in the script shebang line).
In perl 5.8.1, -I doesn't seem to taint @INC:
% perl -MScalar::Util=tainted -I/foo/bar -T -le 'print tainted($_) for
@INC'
0
0
0
0
0
0
0
0
0
Maybe it should?
-Ken
Re: efficient module version checking without loading the module?
On Mar 24, 2004, at 2:20 PM, Stas Bekman wrote: That's said, it'd be great to see the perl test suite run all its tests under -T. I thought we have discussed this about a year ago or so. I'm not sure that's a good idea. Aren't there tests in the suite that invoke system-level operations on data that comes from outside the test scripts? -Ken
Re: efficient module version checking without loading the module?
On Mar 25, 2004, at 2:31 PM, Stas Bekman wrote: So if you *do* trust require() of a random file to acquire its version, you ought to trust parse_version_untaint_source() just the same. It's not obvious to me that eval-ing an arbitrary (or semi-arbitrary) line of a file is always as safe as eval-ing the entire file. Consider the following highly contrived example: package FoolMeTwice; my $string = 'EOF'; $VERSION = 5; system(rm -rf /); EOF $VERSION = 6; __END__ That will do almost nothing with use FoolMeTwice;, but doing parse_version_untaint_source() will wreck your system. Maybe there are no non-contrived examples, though. -Ken
Re: Distributed testing idea
Some thoughts: 1) In order to be convenient for the code author, he/she should be able to poll for available clients before submitting a job. My inclination would be to make this a simple inetd on the client, rather than any persistent connection between client server. I think if there were daemons on the client, or if the client had to connect to a daemon on the server, lots of clients would forget to do it when they rebooted. 2) I'd be very hesitant to let anyone do this on my machine. I don't worry [much] about malicious code, but when I'm testing non-ready-for-CPAN code, I have done some pretty dumb things. At the very least, I'd create a new user account for the testing processes and give it very low priorities. I also think I'd want to set it up so that I only give access to certain code authors, and they *MUST* be properly signed with a SIGNATURE file. 3) I'd sure be interested in it for Module::Build. -Ken
Re: U/WIN small fix
On Thursday, October 30, 2003, at 10:43 PM, Michael G Schwern wrote:
On Thu, Oct 30, 2003 at 11:33:41PM -0500, Randy W. Sims wrote:
In MM.pm change
$Is{UWIN} = 1 if $^O eq 'uwin';
to
$Is{UWIN} = 1 if $^O =~ /uwin(?:-nt)/;
You mean /^uwin(-nt)?$/ right?
Thanks. perlport could also use some information about uwin's $^O.
Yeah, I don't have uwin on my radar screen for Module::Build since it
wasn't in perlport. Is it a flavor of Windows?
-Ken
Re: [Fwd: Re: MARC: msg 'cvs commit: modperl .cvsignore']
On Tuesday, October 14, 2003, at 04:16 PM, Stas Bekman wrote: Michael, any idea why the default behavior is to always overwrite META.yml? As more projects will start maintaining it, they all will have to specify NO_META. Shouldn't it be the opposite: overwrite only if explicitly told to? I think most projects would want the META.yml overwritten by default. I certainly do in my projects, because it will update all the information for me. I don't think many people are maintaining the metadata by hand like you are. -Ken
Re: Recipe to detect C compiler availability
On Thursday, September 18, 2003, at 01:54 AM, Iain Truskett wrote: Heyo, I was wondering if there was a nice recipe to determine whether a C compiler is available. The various modules I looked at that have both XS and pure perl implementations don't seem to have any sort of standard method of determination. Runtime isn't a problem since the C based implementation would have a different name from the Perl one, but I don't know a recommended way to work out whether to bother compiling at 'make' time. In Module::Build, this is pretty easy - I'm adding a have_compiler() method that does Nick's test caches the result. -Ken
Re: perl562@20985 [PATCH MakeMaker]
On Monday, September 8, 2003, at 01:11 PM, Orton, Yves wrote:
I've actually patched the docs to say that it will look at $ENV{PATH}
or the local equivalent. I think this is best, because the
caller code shouldn't have to figure out what string to pass it.
This isnt the point. Its not an uncommon situation to need to split a
path like variable in a platform intelligent way.
Consider that perl itself has several such variables. PERLLIB and
PERL5LIB.
If you dont provide a way for a user to pass in variables to split
then the routine is not generally useful and people will be
reinventing this particular wheel (and probably badly) every time they
have a path like variable in their config file or whatever.
In my understanding, the only strings that $Config{path_sep} is
supposed to split are PATH, PERLLIB, and PERL5LIB. It's not supposed
to be used for various generic configuration elements.
In general it's bad form to just tell the user a
To specify the behavior completely you'd also have to tell them quoting
and escaping rules.
I'd rather provide APIs to access the data in these variables, than
provide methods that the caller would use to do the data manipulations
him/herself. I don't want to encourage the use of $Config{path_sep} in
user code beyond what it was intended for - much better to use a real
serialization technique like Data::Dumper or the like.
I suppose one could always say
my @parts=do {
 local $ENV{PATH}=$the_path_i_need_split;
 File::Spec-path()
};
but personally I think thats ridiculous.
Yes, of course.
It already looks at $ENV{PATH}, $ENV{Path}, and $ENV{path} for Win32,
since before I started maintaining the module.
As regarding looking at $ENV{PATH} and $ENV{Path} and $ENV{path} I
dont understand this. All three return the same thing. ENV settings on
Win32 arent case sensitive.
I don't understand it either, but I'm loath to remove it without
understanding it. My guess is that it checks the variants *because*
ENV settings on Win32 aren't case-sensitive, and any of those variants
(plus 13 others) could be set.
-Ken
Re: ExtUtils::MakeMaker 6.16, site/vendor dirs patch
Ville reported this for Module::Build too (https://rt.cpan.org/Ticket/Display.html?id=3703), and while the patch is much simpler (only 4 lines) I'm still debating whether to apply it since it works around a fixed bug in beta candidates. Then again, Red Hat 9 has really thrown a wrench into the works, and is probably important enough to warrant a fix. What's your opinion on it, Schwern? -Ken On Tuesday, September 2, 2003, at 05:28 PM, Ville Skyttä wrote: Hello, I'm trying out ExtUtils::MakeMaker on Red Hat 9, and have found a problem. RH 9 comes with Perl 5.8.0 which has some patches from 5.8.1-RC* applied.
Re: Don't mess with the PASTHRU semantics.
On Thursday, August 7, 2003, at 10:27 PM, Michael G Schwern wrote: Leave it be. If it gets rushed into 5.8.1, something's going to break because of it. Its been broken for a long time, it can wait. After 5.8.1 we'll take a stab at fixing it, Steve's problem is not urgent enough to risk breaking other modules. I agree, the right time to try fixing something like this is right *after* a release like 5.8.1, not right before. -Ken
ANNOUNCE: Module::Build 0.19 released
Hi,
The uploaded file
Module-Build-0.19.tar.gz
has entered CPAN as
file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.19.tar.gz
size: 74015 bytes
md5: c1647888d63033446583f9697fb7b426
Oodles and oodles of changes since 0.18:
- Added support for the 'install_path' parameter, which allows custom
specification of where things should be installed. This is a major
improvement to Module::Build's functionality.
- Added the 'install_base' parameter. Provides an easy way to
install to local or alternative directory trees.
- We now install scripts by default to $Config{installsitebin}
instead of $Config{installscript}. Neither is a great choice, but
the former is likely to be [analogous to] /usr/local/bin, and the
latter is likely to be [something like] /usr/bin . If/when there's
a $Config{installsitescript}, we'll start using that automatically.
- Fixed a problem on Win32 in which C and XS files wouldn't be
compiled properly, and the user would see an error about 'Can't
locate object method format_compiler_cmd'.
(http://rt.cpan.org/Ticket/Display.html?id=2391)
- We now use the correct perl interpreter (via
Module::Build-find_perl_interpreter) in pass-through makefiles.
- The t/compat.t test now uses $Config{make} instead of just 'make'
to test makefile compatibility. This fixes some failures on Win32.
We also skip this test entirely if no make utility is available.
- Alternative distribution layouts are now supported via the
'pm_files', 'pod_files', 'xs_files', 'PL_files', and 'script_files'
parameters to new(). This should help people transition from
MakeMaker, and might even help us write an automatic transition
tool.
- Added tests to t/runthrough.t that check to see installation is
happening correctly.
- Added experimental code to build a .ppd file, in support of
ActiveState's Perl Package Manager. [original patch by Dave
Rolsky]
- For authors who use Module::Signature to sign their distributions,
we now create the SIGNATURE file right in the distribution
directory, rather than creating it in the top-level directory and
copying it into place. This solves problems related to having
files get out of date with respect to their signatures.
- We now don't depend on Module::Info to scan for packages during the
'dist' action anymore, because it's way too aggressive about
loading other modules that you may not want loaded. We now just
(ick, yuck) scan the .pm files with a regular expression to find
package Foo::Bar; statements.
- Silenced some annoying copyright/logo output from Microsoft 'nmake'
during Makefile compatibility testing. [Randy W. Sims]
- Command-line arguments may now either be specified using the syntax
'--foo foovalue' as well as the traditional syntax 'foo=foovalue'.
The former is often more convenient for shell tab-completion when
the value is a filename (as in 'Build test --test_files t/basic.t').
- Command-line arguments may now include non-named parameters, which
make some actions more natural. For instance, the 'diff' action
may now be invoked as 'Build diff -u' rather than as
'Build diff flags=-u'.
- Pass-through Makefile.PLs now convert unknown Makefile.PL
parameters to lower-case and hand them to Build.PL, rather than
ignoring them. This means we only have to account for the
differences in the interface, not the entire interface, in
translating parameters.
- We now issue a warning don't proceed if asked to make a distdir
and there's no MANIFEST or it's empty.
- Moved INSTALL to INSTALL.txt to increase compatibility with various
odd versions of 'make' during 'make install' on case-insensitive
filesystems (like nmake on Win32, often). Only affects the
Makefile compatibility layer. [reported by Andrew Savige]
- Module::Build-known_actions() now works as a class method.
- Pass-through makefiles now list each action individually rather
than using a .DEFAULT catch-all. This improves compatibility
with 'nmake' on Win32, and probably some other less common 'make'
dialects. [Andrew Savige]
- We're now more aggressive about testing the pass-through makefiles,
e.g. making sure they can run 'all' and 'test' targets, and making
sure the Makefile itself actually exists.
- Fixed a problem with check_installed_status() when installed
version contains non-numeric characters like underscores.
- Fixed a problem with a bareword 'File::Spec' in one of the test
scripts that caused it not to compile under 5.8.0 (but is fine
under 5.6).
- Fixed a problem with the 'destdir' installation parameter on
platforms that have volume identifiers in path names (like C: on
Win32). The identifier is now stripped from installation
directories before prepending the destdir path. The destdir path
may still have a volume identifier on it.
- Added an 'add_to_cleanup' parameter to new() that calls
Re: Which 'make' program on Windows?
On Wednesday, June 25, 2003, at 04:17 PM, Ed Avis wrote: I know this should be an easily-answered question, but I couldn't find the answer in the ExtUtils::MakeMaker manual page or in ExtUtils::MakeMaker::FAQ. When MakeMaker runs on Windows, what make program does it have it mind when writing the makefile? Microsoft's nmake? Yup. Should GNU make work? I have no idea. ;-) Does it depend on what options perl was built with, and is there any way to find out what MakeMaker is thinking? Yup, you can run perl -V:make at the command line, which pulls info out of Config.pm: % perl -V:make make='make'; (this is on an OS X system, not Win32.) -Ken
Re: Perl 5:8.0, MM:MakeMaker and PREFIX is broken
On Monday, June 16, 2003, at 08:39 AM, [EMAIL PROTECTED] wrote: Please keep CC, I'm trying to package grepmail (SF project) as Cygwin Net release and to do that I need to instruct MakeMaker to install under separate directory, but just like as it would normally. $ perl Makefile.PL $ grep -i prefix Makefile PREFIX = /usr SITEPREFIX = /usr VENDORPREFIX = That installs fine as system wide, but not if I do this with grepmail: $ perl Makefile.PL FASTREADER=0 INSTALLDIRS=perl PREFIX=.inst/usr $ grep -i prefix Makefile PREFIX = .inst/usr SITEPREFIX = .inst/usr VENDORPREFIX = .inst/usr It smells to me like you should really be setting DESTDIR=.inst instead of PREFIX=.inst/usr . -Ken
Re: MakeMaker choosing the C compiler used.
On Thursday, June 12, 2003, at 05:52 PM, Kurt Starsinic wrote: On Jun 12, Matthew A. R. Sherian wrote: I am attempting to discern how makeMaker chooses the C compiler used. I am having an issue where make maker is picking the wrong compiler on a Solaris 9 box. I have gcc 3.2.3 installed and no versions of cc. However make maker is picking cc most of the time. Can you point me at some info regarding the methodology by which the C compiler is chosen Type `perl -V:ccname'. Whatever it says is what is used. If you're having this problem with a specific module, that module might be setting the CC configuration variable explicitly to 'cc' or something. Look for that too. -Ken
Re: MM and filename case (was Re: MakeMaker alpha... so, any problems?)
On Friday, June 6, 2003, at 07:04 PM, Michael G Schwern wrote: On Thu, Jun 05, 2003 at 08:45:00AM -0500, Ken Williams wrote: Oh, you're describing how to determine how the current system deals with cases. I was describing how to determine the casing of a file when you already know you're on a case-insensitive, case-preserving FS. Can't you just look at readdir()? Yeah, you can (that's what Stas suggested), but it's pretty wasteful to read an entire directory just to figure out the proper casing of a single file. O[# of files in the directory] when it should be O[1]. -Ken
Re: MM and filename case (was Re: MakeMaker alpha... so, any problems?)
On Thursday, June 5, 2003, at 01:11 AM, Michael G Schwern wrote: On Wed, Jun 04, 2003 at 10:23:58AM -0500, Ken Williams wrote: Well, your technique of reading the entire directory just to get the proper-case name of a single file is no Cat Pajama Suit either. The only real way to handle it properly if you have no advance knowledge of the filesystem is to query the OS for the proper casing. Mac OS X has this ability, it's probably available in other case-insensitive case-preserving environments too if we wanted to bother with it. A far simpler thing to do is just write out a mixed-case filename and see what you get back from readdir() to test for case preservation. For case sensitivity, just write out a filename and try to open it with a different casing. Oh, you're describing how to determine how the current system deals with cases. I was describing how to determine the casing of a file when you already know you're on a case-insensitive, case-preserving FS. -Ken
Re: Latest MM and ExtUtils::ParseXS
On Friday, April 4, 2003, at 04:06 AM, Michael G Schwern wrote: On Mon, Mar 31, 2003 at 08:27:17PM -0600, Dave Rolsky wrote: Well, it found ExtUtils/xsubpp in the new location, which is good. But then it expected to find a typemap file in the same location, which is bad. I'm not sure what the right solution is. Either MM has to look for these separately, or EU::ParseXS should install a typemap file. Ewww, typemap files. Fear. Flee. Yeah, I certainly don't pretend to understand typemaps, though I've been able to get good use out of them. When I first shipped MakeMaker as a CPAN module, I'd included the bleadperl typemap file along with it. I was told not to do that because its very version specific. Hmmm. I guess I'll just decopule the two. I'll give the typemap location its own macro but only look for it in the perl core directory. That sounds like the right thing to do. No need to couple 'em. -Ken
Re: make disttest issues
On Friday, March 21, 2003, at 02:26 PM, Geoffrey Young wrote: hi all... I didn't realize that such a list existed, but it's a much better place to post my, um, feature report than p5p :) appologies if I'm posting to the wrong place. anyway, I noticed the other day that the disttest target seems to have an issue - at least for one of the ways that Apache::Test lets you use it. given $ perl Makefile.PL -apxs /usr/local/apache2/bin/apxs disttest leaves off the additional configuration stuff and just calls perl Makefile.PL. I wasn't aware that 'make disttest' was supposed to add any other arguments to its 'perl Makefile.PL'. Is that documented somewhere? Seems like maybe what you want to do is just 'make test', unless I'm misunderstanding. anyway, I guess the routines in Apache::Test that parse additional command-line arguments are non-standard, but it would be nice to support this feature, especially since there are other targets that seem to store this information just fine. I think it's pretty common for Makefile.PLs to take other command-line options. -Ken
Re: make disttest issues
On Sunday, March 23, 2003, at 02:17 PM, Michael G Schwern wrote: On Sun, Mar 23, 2003 at 09:19:04AM -0600, Ken Williams wrote: anyway, I noticed the other day that the disttest target seems to have an issue - at least for one of the ways that Apache::Test lets you use it. given $ perl Makefile.PL -apxs /usr/local/apache2/bin/apxs disttest leaves off the additional configuration stuff and just calls perl Makefile.PL. I wasn't aware that 'make disttest' was supposed to add any other arguments to its 'perl Makefile.PL'. Is that documented somewhere? Ahh, of course! disttest, simulating what happens when you distribute your module, shouldn't pass through your local command line options. Unless someone has a convincing argument otherwise. Yeah, that's what I was thinking. It's supposed to be similar to an automatic smoke test or the like. -Ken
Re: 'make dist' now adds META.yml
On Saturday, March 8, 2003, at 11:41 AM, Jochen Wiedmann wrote: thanks for the pointer Ken. I have carefully read the thread and found nothing that convinced me. In fact I have missed some arguments: - data files generated by Data::Dumper can be evaluated in a Safe compartment. It's not malicious code we're (at least, I'm) worried about, it's the fact that code is being eval-ed. As soon as you make it eval-able perl code instead of a static data definition language, someone is going to put something like ($^O =~ /Win/ ? Foo::Win32 : Foo::Generic) in there, and now we don't have a static list of dependencies anymore. If it's not static, what's the point in extracting it out of the Makefile.PL? That said, malicious code is probably a real issue too, because these files shouldn't be able to *do* anything, they should just contain some data. The hope is that these files will be used in lots and lots of situations by lots of different parties, and we can't make sure *all* of them use Safe.pm in a tight way. Nor is Safe.pm very tight in the first place. One need only look at the following to see why: http://search.cpan.org/author/ABERGMAN/Safe-2.09/ Safe.pm#Some_Safety_Issues - An XML Writer would be required by the module author only. An XML Reader is already part present on most systems, with a definitely growing number. I'm not eager to write the code that senses around for whatever weird XML reader might be present on whatever weird system, though. And this says nothing about systems that were built and deployed three years ago, which won't have one unless we require them to install it. - I recently started to have a look at Module::Build and I wholehearty support it: In particular, because it will finally simplify module installation on Windows and commercial Unix systems, where one typically doesn't have a C development environment. But my guess its most important problem for acceptance will be its dependence on esoteric modules like YAML or ExtUtils::ParseXS. (Esoteric == not part of the ActiveState repository, aka target group) *I* (module author) had no problem installing these prerequisites, but I wouldn't like to receive 10 emails a week asking How do I install these modules? I agree completely with these sentiments. If you look at the actual list of required dependencies for Module::Build, you'll see that they're all present in the perl 5.6.0 core. The other things like YAML and ParseXS are only *recommended* dependencies, but unfortunately CPAN.pm reports them as required. (actually, this might be fixable in Module::Build rather than requiring a CPAN.pm patch.) Note that M::B can use either the regular xsubpp script in core perl, or ExtUtils::ParseXS, which is a safer and more compartmentalized way to achieve the same thing. In any case though, for the M::B project to move forward and do things that MakeMaker hasn't been able to do easily, it may require people to install some more modules. - You think XML isn't human readable? What do you expect the typical joe user to do, if she or he finds an unknown file? Double-clicking it! In the case of XML that means, that a properly configured browser opens the file, formats it nicely, highlights tags, offers to hide or view sections. That's true. I'm not sure I expect someone who doesn't know how to read a simple text file to be poking around in Perl module source directories much, though. - You happy guys seem to live in a Perl-only world. My Envy! I don't and most other peoples also do. However, in a heterogenous world, a portable data format is worth much more than a data format that requires me to write a parser. Why in the world would you be required to write a parser?? Your arguments seem to be sort of against YAML in the abstract - do you have a particular application involving the META.yml file that is going to be more difficult because of the choices that have been made? I do appreciate your point of view, but I can also tell you that for every person that asks why we're not using XML for this, there's another person who's written me telling me how glad he/she is that we're not. -Ken
Re: 'make dist' now adds META.yml
On Friday, March 7, 2003, at 03:04 AM, [EMAIL PROTECTED] wrote: Forgive my terseness, but this discussion has already been done in all possible permutations. Below are the conclusions reached. If you wish to continue discussing, I'd be happy to do it in private but I really, really DO NOT WANT ANOTHER XML VS YAML DISCUSSION. Not on this list anyway. For those that want to see a previous incarnation of this discussion, see http://archive.develooper.com/[EMAIL PROTECTED]/msg00405.html -Ken
Re: 'make dist' now adds META.yml
On Thursday, March 6, 2003, at 08:38 AM, [EMAIL PROTECTED] wrote: The META.yml file is intented to be compatible with Module::Build's and currently looks something like this: #XXX This is a prototype!!! It will change in the future!!! X# name: ExtUtils-MakeMaker version: 6.06_03 version_from: lib/ExtUtils/MakeMaker.pm installdirs: perl requires: File::Spec:0.8 File::Basename:0 DirHandle: 0 Pod::Man: 0 distribution_type: module generated_by: ExtUtils::MakeMaker version 6.06_03 The only thing that sticks out at me is the installdirs key - is that really meta-data about the distribution? It seems like it's a choice the user makes when installing. Also, there's no license key here. Is it possible to generate that from anything? -Ken
Re: MakeMaker Is DOOMED!
On Monday, February 17, 2003, at 04:14 AM, Tim Bunce wrote: Actually the name originates from the 'ext' subdirectory of the perl distribution. But you're right that it's very much a legacy. Oh, I didn't know that, it makes a lot more sense than external utils, which is what I thought it meant too. Of course, this means that the namespace is even worse than I thought for being used as general-purpose module-handling schtuff. =) -Ken
Re: [Module-build-general] MakeMaker Is DOOMED!
On Sunday, February 16, 2003, at 01:35 PM, Brian Ingerson wrote: I went to the talk. It got me to thinking about CPAN::MakeMaker and its relationship to Module::Build. Given: The goal of CP::MM is to allow authors to write very simple/clean Makefile.PLs that can potentially turn on very powerful features like bundling with the flick of a switch. The Makefile.PL produces a Makefile. Then: There is no reason why CP::MM can't produce a Makefile that wraps Module::Build! I'm not sure that's ideal, because it still requires 'make' to orchestrate at least some of the process. One of the hairiest parts of Module::Build is the tiny little pass-through Makefile in Module::Build::Compat, because it has to work in all kinds of different environments. I've just made a bunch of changes that let it work on Windows, but there are still a bunch of things missing, like translating MM command-line options to M::B options If the author has a version of Module::Build on there system that is sufficient to handle the options that the author has requested of CPAN::MakeMaker, then CP::MM will (optionally??) bundle M::B into the author's dist. After that nobody is the wiser. Everything just works. I wouldn't want lots of installation tools bundled into all my distributions, though. I still think it's far better to have a powerful system for listing dependencies in as fine-grained and accessible a manner as is necessary, and let the user choose their favorite policies and tools for fulfilling those dependencies. -Ken
Re: [Module-build-general] MakeMaker Is DOOMED!
On Thursday, February 13, 2003, at 03:30 AM, [EMAIL PROTECTED] wrote: Tonite at Portland.pm I gave a lightning talk entitled MakeMaker Is DOOMED! or MakeMaker Is Dead! Long Live Module::Build!. Excellent. =) I should bring a Grim Reaper mask to YAPC/TPC this year. -Ken
Re: MakeMaker only looks for xsubpp in $Config{privlibexp}
Hi Randy, I'm about to go out of town for the week[end], but I thought I'd address the easy points. ;-) On Tuesday, February 11, 2003, at 05:25 PM, Randy W. Sims wrote: I agree. Running xsubpp on such a file does nothing but make a copy. The module in question is in libwin32. ( Which, along with Tk, seemed like a good testbed because they contain alot of XS modules. ) Yeah, it would make a good testbed - but I have no access to a win32 system, so I'll have to let you test in that arena. The test script is probably going to be the biggest problem with this module because of the number of different OSs and compilers used to build perl, which is why I was really hoping someone might have a better suggestion than my hack. Maybe you could invoke xsubpp on the test module to verify that it produces a non-empty file, then invoke MM to build the test module ( It would be nice if there were a module specifically for invoking the compiler linker. There are quite a few modules I can think of that would benifit from it. ) Absolutely. I've gotten surprisingly good results in Module::Build with just straightforward system() calls, or at least people haven't submitted bug reports. But it would be cool to abstract this away somewhere. (I'd also like to fix the Use of uninitialized value in join or string at /Users/ken/src/modules/ExtUtils-ParseXS/blib/lib/ExtUtils/ParseXS.pm line 798, File line 14 error before 2.00, but I don't know what's causing it.) I don't recall seeing that message. Do you see it when building a particular module? I see it when running 'make test' for ExtUtils::ParseXS. P.S. IRC, I had problems installing this module when you first announced it on P5P due to the version having an underscore in it ( I think it was 1.98_01 at the time ). I don't remember the details now; I didn't spend much time with it then due to the holidays and a general lack of time. Yeah - CPAN.pm won't install a module with underscores, because it considers it a beta version. That's actually the very reason I used the underscores for the first release. -Ken
Re: MakeMaker only looks for xsubpp in $Config{privlibexp}
On Sunday, February 9, 2003, at 01:14 PM, [EMAIL PROTECTED] wrote: On Sat, Feb 08, 2003 at 06:35:59PM -0800, Ken Williams wrote: 2) To workaround, how do I get MakeMaker to install xsubpp in PERL_LIB? You probably should install ExtUtils::ParseXS with INSTALLDIRS=perl (give that argument to WriteMakefile) on general principles. ExtUtils::xsubpp is a core module, so it should go into the core (ie. perl) directories. Unfortunately, ExtUtils::ParseXS probably shouldn't, but there's no easy way to split them up and its not worth the bother. Great - you and Randy gave the same advice, so I suppose that's what I'll do. The more I encounter these kinds of situations under MM, the more I think that the mantra for directory targeting under Module::Build needs to be something like as simple as possible, or perhaps simpler. -Ken
MakeMaker only looks for xsubpp in $Config{privlibexp}
Hi Schwern and so on,
The ExtUtils::ParseXS, which is now on CPAN, provides functionality
equivalent to the 'xsubpp' script, and replaces xsubpp on the user's
system with a wrapper script around the ExtUtils::ParseXS functionality.
However, it installs this wrapper script in site_perl/ (or wherever the
user installs modules), and MakeMaker only looks for xsubpp at
PERL_LIB/xsubpp - see MM_Unix.pm line 3910 in CVS:
my($xsdir) = File::Spec-catdir($self-{PERL_LIB},ExtUtils);
... then later ...
XSUBPPDIR = $xsdir
XSUBPP = \$(XSUBPPDIR)/$xsubpp
The PERL_LIB setting defaults to $Config{privlibexp}.
So the issues are the following:
1) Shouldn't MM look for xsubpp anywhere in @INC?
2) To workaround, how do I get MakeMaker to install xsubpp in PERL_LIB?
-Ken
Strange installation dirs problem
Hi, A funny thing just happened when installing a local module with the latest MakeMaker from CVS. I installed it manually (no CPAN.pm), then tried to use it, and it wasn't found in @INC. It turns out that the module was installed to /sw/lib/perl5/site_perl/, but that's not in my @INC, nor is it in my Config.pm. So it seems that MakeMaker (or ExtUtils::Install?) has invented this path rather than using what it's supposed to be using. In this situation, /sw/lib/perl5 is in my @INC, so perhaps MakeMaker is blindly assuming that a site_perl directory there is the place to put stuff? I'm not sure whether it existed before this installation or not. -Ken
'Makefile' now depends on $(VERSION_FROM)?
Hey,
Between -r1.107 and -r1.108, the VERSION_FROM file was added as a
dependency to the Makefile. This is kind of a pain - in fact, it's a
well-known, documented pain:
The file named in VERSION_FROM is not added as a depen-
dency to Makefile. This is not really correct, but it
would be a major pain during development to have to
rewrite the Makefile for any smallish change in that
file. If you want to make sure that the Makefile con-
tains the correct VERSION macro after any change of the
file, you would have to do something like
depend = { Makefile = '$(VERSION_FROM)' }
(from the MakeMaker POD documentation)
So, maybe this could be removed, using the following patch?
===
RCS file: /home/schwern/cvs/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm,v
retrieving revision 1.140
diff -u -r1.140 MM_Unix.pm
--- lib/ExtUtils/MM_Unix.pm 24 Dec 2002 04:47:08 - 1.140
+++ lib/ExtUtils/MM_Unix.pm 20 Jan 2003 06:09:06 -
@@ -2886,7 +2886,7 @@
push @m, q{
# We take a very conservative approach here, but it\'s worth it.
# We move Makefile to Makefile.old here to avoid gnu make looping.
-$(FIRST_MAKEFILE) : Makefile.PL $(CONFIGDEP) $(VERSION_FROM)
+$(FIRST_MAKEFILE) : Makefile.PL $(CONFIGDEP)
$(NOECHO) echo Makefile out-of-date with respect to $?
$(NOECHO) echo Cleaning current config before rebuilding Makefile...
$(NOECHO) $(RM_F) $(MAKEFILE_OLD)
===
Alternatively, it could be fixed so that the dependency is really on
the version number, not the file. But that would be quite a bit more
work.
-Ken
ExtUtils::ParseXS - CPAN
The uploaded file ExtUtils-ParseXS-1.98_01.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/ExtUtils-ParseXS-1.98_01.tar.gz size: 20294 bytes md5: 7f5e33fe81c051ecba769f6f532b2206 This wraps the functionality of xsubpp into a module interface. I'm using it for Module::Build, falling back to running xsubpp if ParseXS isn't installed. -Ken
Re: [craigberry@mac.com: Re: MM snapshot status on VMS (was Re: [PATCH MM 6.05] ppd and hints portability nits)]
On Wednesday, November 20, 2002, at 06:56 PM, Craig A. Berry wrote: At 5:27 PM +1100 11/20/02, Ken Williams wrote: On Wednesday, November 20, 2002, at 04:06 PM, Michael G Schwern wrote: 2.) my($key) forces list context but the result of a match can only be stored in a scalar lvalue 3.) The result of a match is just a boolean, not the thing matched, so $key would never have the unadorned macro name but that should be in $1. Nope, the original code would work. You are of course correct that list context should capture matched values (Camel 3, p. 150). However, I think code has to compile before it will work :-) Heh - guilty as implicitly charged. =) Mainly I wanted to make sure that the list context thingy was understood. I didn't try this code, because, well, I'm not on VMS. =) -Ken
Re: There's nothing magic about MAKEFILE is there?
On Friday, November 15, 2002, at 06:40 PM, Michael G Schwern wrote:
I noticed something funny. All over MakeMaker, the contents of
$self-{MAKEFILE} are hardcoded into the Makefile. Why is there no
$(MAKEFILE) macro? Does it mean something special? I see GNU make
considers MAKEFILES special.
Unless someone can think of a reason otherwise, I'm going to
add $(MAKEFILE)
and cut out all those $self-{MAKEFILE} hardcodes.
I don't know whether MAKEFILE is special, but in
Module::Build::Compat I use THISFILE instead, which shouldn't
have any problems.
-Ken
Re: META.yaml
On Friday, November 15, 2002, at 09:26 AM, Michael G Schwern wrote: It hit me while raking leaves today that it would be absolutely *trivial* for MakeMaker to do the same. All the meta-data already exists in the MakeMaker object. All that's needed to be done is spit out the file. As I mentioned privately to Schwern, the only objection I have is that Module::Build still needs to be better at *something*. =) Seriously though, I still have enough faith in the M::B architecture and so on that I think stuff like this isn't an actual threat to its adoption. We're following Module::Build's lead here and using its formats and decisions as much as possible. (Un|)fortuately, its all very flexible and somewhat undocumented at the moment. So we're going to be making things up as we go along. That's true. Currently M::B doesn't *use* the META.yaml file, it only produces it for external tools to use. When trying to figure out fields for the META.yml file, a nice point of reference to use is dpkg and the Debian Policy Manual http://www.debian.org/doc/debian-policy/ They've solved a lot of the hard packaging problems. That's what I've been following, or at least inspired by. I've seen it work really nicely in fink, for example. [3] Module::Build uses META.yaml. We have to use .yml for 8.3 filesystems. Ken, can Module::Build be changed to match? Done. -Ken
Re: Win32: C:\Program Files
On Thursday, November 14, 2002, at 09:07 AM, Michael G Schwern wrote:
Ok, here's what's gone in. It should solve both the 21
problem on Win9X
and the C:\Program Files\perl\bin\perl problem, at least in
find_perl().
This means MM_Win32-find_perl can go away.
[...]
-1084,12 +1097,18
print Checking $abs\n if ($trace = 2);
next unless $self-maybe_command($abs);
print Executing $abs\n if ($trace = 2);
- $val = `$abs -e 'require $ver; print VER_OK\n ' 21`;
- if ($val =~ /VER_OK/) {
+
+# To avoid using the unportable 21 to supress STDERR,
+# we close it before running the command.
+close STDERR if $stderr_duped;
+$val = `$abs -e require $ver; print qq{VER_OK\n}`;
+open STDERR, 'STDERR_COPY' if $stderr_duped;
Is there no way to use the multi-arg system() to avoid these
quoting issues altogether?
-Ken
Re: [bug] 6.05 parse_version
On Thursday, November 14, 2002, at 12:13 PM, Michael G Schwern wrote: On Thu, Sep 05, 2002 at 09:41:35AM +0800, Stas Bekman wrote: Moreover this bug doesn't exist in MM 6.03, but does exist in 6.05 and versions prior to 6.00. I don't see how that's possible. The last minor change to parse_version() or the logic calling it was around 5.93_01. The last significant change was before I took over (so somewhere before 5.48_04). Anyhow, I concur with Andreas. The current heuristic stays. It might not be smart, but at least its easy to predict. And unfortunately, the heuristic is *documented*, which means it's gone from being a heuristic to being an interface. Not that there were a whole lot of alternative ways to do it. I think it's a decent way of solving the problem, actually. To really solve it cleanly would require a change in the way Perl sets/gets version numbers. -Ken
Re: Win32: C:\Program Files
On Thursday, November 14, 2002, at 03:42 PM, Michael G Schwern wrote:
On Thu, Nov 14, 2002 at 02:21:35PM +1100, Ken Williams wrote:
-1084,12 +1097,18
print Checking $abs\n if ($trace = 2);
next unless $self-maybe_command($abs);
print Executing $abs\n if ($trace = 2);
- $val = `$abs -e 'require $ver; print VER_OK\n ' 21`;
- if ($val =~ /VER_OK/) {
+
+# To avoid using the unportable 21 to supress STDERR,
+# we close it before running the command.
+close STDERR if $stderr_duped;
+$val = `$abs -e require $ver; print qq{VER_OK\n}`;
+open STDERR, 'STDERR_COPY' if $stderr_duped;
Is there no way to use the multi-arg system() to avoid these
quoting issues altogether?
Ed's original patch tried that.
http://archive.develooper.com/makemaker;perl.org/msg00199.html
As you can see its more work and involves temp files (Ed's patch
forgets to
cleanup after itself). And its incomplete since it would have to read
the
output from the file to which STDOUT was redirected to make sure the
VER_OK
was printed rather than just relying on the exit value as the more
modern
version of find_perl() does. [1]
Oy, though. It's doing more work than it needs to. Why not just check
the exit value?
my $ok = !system($abs, '-e', exit !eval 'require $ver; 1');
-Ken
Re: Win32: C:\Program Files
On Thursday, November 14, 2002, at 04:26 PM, Michael G Schwern wrote:
On Thu, Nov 14, 2002 at 04:12:51PM +1100, Ken Williams wrote:
Oy, though. It's doing more work than it needs to. Why not
just check
the exit value?
my $ok = !system($abs, '-e', exit !eval 'require $ver; 1');
$ perl -wle 'print Its perl! if !system(/bin/true, -e,
exit !eval q{require 5.005; 1})'
Its perl!
For some reason I didn't realize what the problem was, so I
didn't realize you'd already solved it either. =) On to other
matters...
-Ken
Re: [bug] 6.05 parse_version
On Monday, November 11, 2002, at 03:22 PM, Stas Bekman wrote:
Andreas J. Koenig wrote:
Asking an author to include a $VERSION is a fair request.
$VERSION-less scripts and modules are a major PITA, no matter if it's
for MakeMaker or for somebody else.
Well, usually there is one $VERSION per a collection of several files.
But sure this workaround should be OK.
Another workaround would be to disguise the $VERSION line:
no strict 'vars';
unless (${'File::Spec::V' .'ERSION'} = $min_version) {
...
Or even better:
unless (File::Spec-VERSION = $min_version) {
...
In any case. Any reason why the parse_version isn't using eval and
avoiding fatal errors? If it fails to get the version, just move on,
don't screw the output of CPAN.pm in this particular case. I suppose at
least CPAN.pm could wrap this call in eval().
I think that by finding a VERSION MakeMaker has committed to thinking
that there's a real VERSION in the file, and then it dies because its
commitment was wrong. This is documented - the MakeMaker docs say that
the first line matching
/([\$*])(([\w\:\']*)\bVERSION)\b.*\=/
will be treated as a version number. I don't really like it any more
than you do, but it's behaving as documented.
-Ken
Re: INSTALLSCRIPT doesn't have 'site', 'vendor' values?
On Thursday, November 7, 2002, at 05:56 PM, Andreas J. Koenig wrote: On Thu, 7 Nov 2002 13:18:17 +1100, Ken Williams [EMAIL PROTECTED] said: Okay. I'll wait a week or so for someone like Andreas or Andy to chime in and explain why there are no other INSTALL*SCRIPT entries, and if that doesn't happen I'll assume it's an error and I'll try to fix it. Sorry, I have no answer to this one. Would it be wrong to just put scripts into INSTALL*BIN? Do we really need to make a big distinction between executable binaries and executable scripts? The reason for 'script' being separated from 'bin' was that you can share scripts between architectures but usually cannot share binaries. If people actually make use of this distiction, nobody knows. It sounds like the kind of thing someone's going to be using somewhere, so it probably shouldn't get completely broken. If I were to fix this, I think there would be a few parts to it: 1) MakeMaker should try to determine a better place to put scripts (by guessing) 2) EU::Install should honor that 3) Config.pm should have INSTALLSITESCRIPT and INSTALLVENDORSCRIPT entries so MM doesn't have to guess In practice, I don't think any 'hints' files (in 5.8, anyway) have INSTALLBIN and INSTALLSCRIPT different, so it's probably pretty safe to guess from INSTALL*BIN, I think. Then I have to figure out how to cooperate/repeat with Module::Build. -Ken
Re: INSTALLSCRIPT doesn't have 'site', 'vendor' values?
On Thursday, November 7, 2002, at 12:37 PM, Michael G Schwern wrote: On Tue, Nov 05, 2002 at 12:54:22PM +1100, Ken Williams wrote: I'm curious about why INST_SCRIPT doesn't have different values in the three columns. Is this why things like LWP's HEAD script are installing to /usr/bin on OS X instead of to /usr/local/bin? Config.pm has installbin, installsitebin and installvendorbin but only installscript. Dunno why. There's no reason INSTALLSITESCRIPT and INSTALLVENDORSCRIPT couldn't be figured out like the other variables that aren't in Config.pm are. Honestly, I was just sick of the whole PREFIX problem and decided to leave it as is. I'll welcome a patch. Okay. I'll wait a week or so for someone like Andreas or Andy to chime in and explain why there are no other INSTALL*SCRIPT entries, and if that doesn't happen I'll assume it's an error and I'll try to fix it. Would it be wrong to just put scripts into INSTALL*BIN? Do we really need to make a big distinction between executable binaries and executable scripts? I'm ignorant of the important issues, but if we could just use INSTALL*BIN it wouldn't require patching Config.pm and all the stuff that generates it in the perl core. -Ken
Re: INSTALLSCRIPT doesn't have 'site', 'vendor' values?
On Wednesday, November 6, 2002, at 02:49 AM, Soren A wrote: On Tue, 05 Nov 2002 01:54:22 GMT: From: [EMAIL PROTECTED] (Ken Williams) Oh, sheesh. Probably I was an idiot to answer this article of Ken's. I think he's probably well-aware of all the points I made; I momentarily blanked on who this poster was. I think I probably don't have such a high standard as that. =) And in any case, I'm not sure any human could keep track of all the MakeMaker options in his/her head at once. -Ken
Re: INSTALLSCRIPT doesn't have 'site', 'vendor' values?
On Tuesday, November 5, 2002, at 02:15 PM, Soren Andersen wrote: On Tue, 05 Nov 2002 01:54:22 GMT, [EMAIL PROTECTED] (Ken Williams) wrote in news:814B3DD1-F061-11D6-AADE-003065F6D85A;mathforum.org: I'm curious about why INST_SCRIPT doesn't have different values in the three columns. Is this why things like LWP's HEAD script are installing to /usr/bin on OS X instead of to /usr/local/bin? I recently noticed this too. My guess is that there is an assumption that scripts are version-independent (or will take care of version dependency by 'requiring' some version, I s'pose). Therefore no alternative options are built in. It's not so much version issues I'm concerned about, it's the separation of vendor-installed user-installed scripts. I see that my Config.pm has these entries: installbin='/usr/bin' installscript='/usr/bin' installsitebin='/usr/local/bin' installvendorbin='/usr/local/bin' sitebin='/usr/local/bin' sitebinexp='/usr/local/bin' vendorbin='/usr/local/bin' vendorbinexp='/usr/local/bin' On my machine, the correct place for user-installed executables is /usr/local/bin, but unfortunately since there's no such thing as an installsitescript Config entry, they get shoved into /usr/bin, where they can (and do) clobber stuff that Apple installed there. If your Config.pm doesn't contain appropriate values for your system, OTOH, then you may want to edit it. I believe the above entries from my Config.pm are correct, but there still doesn't seem to be any opportunity for MakeMaker to install scripts to a site-specific directory. Schwern, I know you've spend time thinking about these issues, do you know why this is, and/or what should be done about it? -Ken
Re: Differences between MakeMaker's old File::Spec methods and File::Spec.
On Friday, August 30, 2002, at 04:35 PM, Michael G Schwern wrote: Either way, MakeMaker will still need wrappers to deal with older File::Specs. :( Is it not kosher to have modern MakeMakers depend on some minimum version of File::Spec? -Ken
Re: Module::Build design plans
On Thursday, May 23, 2002, at 02:38 AM, Michael G Schwern wrote:
On Wed, May 22, 2002 at 10:31:27AM -0500, Dave Rolsky wrote:
YAML ain't a markup language
It's a data serialization language.
And as long as no one intends that module authors actually
_write_ it (by
text editor) then I think it's just fine.
I'm not quite sure I get this one. What's writing the YAML?
It would be written by YAML as part of the 'make dist' ('Build
dist', actually), from options given in the Build.PL file.
-Ken
Re: Module::Build design plans
On Thursday, May 23, 2002, at 02:55 AM, Michael G Schwern wrote: So we basically still have the moral equivalent of a Makefile.PL, only it's run by the author before distribution to generate a static data file which is distributed avoiding the need to run or parse any code or download and unpack the whole distribution just to get information about the module? Yup, nicely put allinonesentence. ;-) -Ken
mod_perl fails with 5.91_01?
Hey,
Can anyone else verify that mod_perl fails with MakeMaker 5.91_01 ? I
used to be able to compile test with just this:
perl Makefile.PL EVERYTHING=1
make test
Now I'm seeing 'taint' errors up the wazoo:
===
[junior:~/Downloads/perl/mod_perl-1.26] ken% make test
cp t/conf/mod_perl_srm.conf t/conf/srm.conf
/usr/local/src/apache_1.3.23/src/httpd -f `pwd`/t/conf/httpd.conf -X -d
`pwd`/t
httpd listening on port 8529
will write error_log to: t/logs/error_log
letting apache warm up...\c
[Sun Apr 28 12:36:05 2002] [error] Insecure $ENV{PATH} while running
with -T switch at /System/Library/Perl/Cwd.pm line 92.
BEGIN failed--compilation aborted at /Library/Perl/ExtUtils/testlib.pm
line 6.
Compilation failed in require at
/Users/ken/Downloads/perl/mod_perl-1.26/t//docs/startup.pl line 9.
BEGIN failed--compilation aborted at
/Users/ken/Downloads/perl/mod_perl-1.26/t//docs/startup.pl line 9.
Compilation failed in require at (eval 1) line 1.
===
I don't know for sure that this is related to MakeMaker, because I've
also done things like OS upgrades since last time I tried this. I
haven't gone so far as to reinstall an old version of MakeMaker yet.
-Ken
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=darwin, osvers=5.2, archname=darwin
uname='darwin junior 5.2 darwin kernel version 5.2: fri dec 7
21:39:35 pst 2001; root:xnuxnu-201.14.obj~1release_ppc power macintosh
powerpc '
config_args='-des -Dfirstmakefile=GNUmakefile
-Dldflags=-flat_namespace'
hint=previous, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE
-fno-strict-aliasing',
optimize='-O3',
cppflags='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE
-fno-strict-aliasing'
ccversion='', gccversion='Apple devkit-based CPP 6.02',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-flat_namespace -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib
libs=-lm -lc
perllibs=-lm -lc
libc=/System/Library/Frameworks/System.framework/System, so=dylib,
useshrplib=true, libperl=libperl.dylib
Dynamic Linking:
dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-flat_namespace -bundle -undefined
suppress -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under darwin
Compiled at 12/31/01 02:02:01
INC:
/System/Library/Perl/darwin
/System/Library/Perl
/Library/Perl/darwin
/Library/Perl
/Library/Perl
/Network/Library/Perl/darwin
/Network/Library/Perl
/Network/Library/Perl
.
Module::Build design plans
[I just sent this message to the 'Fink' list, I thought it might be of some interest to the people here, too.] Hi, I'm the author of the relatively experimental Module::Build module. It, or something like it, will eventually become the replacement for ExtUtils::MakeMaker (EU::MM). EU:MM needs to be replaced for several reasons, some of which I mention in the Module::Build documentation on CPAN. Michael Schwern, current maintainer of EU::MM, agrees. I want to ask the Fink community what kinds of considerations I should be putting into the design. So far I've been focusing on its flexibility and extendibility in customizing build processes, which I think is already a big improvement over EU::MM. I haven't given much thought to packaging, though, so I'd appreciate any feedback you can give me. Currently in EU::MM, dependencies are handled by a PREREQ field in a function call. This means that it's impossible to programmatically determine dependency hierarchies in advance, which makes automatic installation very tricky (tools like CPAN.pm basically just try to forge ahead, and allow you to auto-install dependencies that fail at runtime). It also doesn't allow for build dependencies, or optional dependencies, etc. I'm thinking of creating meta-data files for Perl modules, similar to Fink's .info files. The first step in the build process (similar to perl Makefile.PL) would read this file and configure itself appropriately. This file would NOT contain Perl code to be evaluated, since this opens up the possibilities of dynamically-determined dependencies. It would just be a flat configuration file. I haven't decided on a format for the file yet, but options might be Fink's format, YAML [1], XML (shudder), or something else. What other things need to be in the info-files? Module (distribution) name should be there, but version should probably not be (they're specified in the module files themselves). Patches aren't relevant, of course. One of the larger goals with this is to get the standard mechanism for building installing Perl modules closer to a real package management system. Currently if you just use perl Makefile.PL make test make install, you don't keep a record of dependencies, and it's very difficult to properly uninstall things later. Thanks in advance for any advice. -Ken [1] http://search.cpan.org/search?mode=modulequery=YAML
Re: MY Errors on compiling mod_perl
On Wednesday, April 24, 2002, at 12:08 PM, Michael G Schwern wrote:
On Wed, Apr 24, 2002 at 10:43:36AM +1000, Ken Williams wrote:
requiring ExtUtils::MakeMaker. MM is one thing. MY is just Wrong.
How is anybody supposed to know that? The docs give examples
like this:
package MY; # so that SUPER works right
sub c_o {
my $inherited = shift-SUPER::c_o(_);
$inherited =~ s/old text/new text/;
$inherited;
}
So one might reasonably expect that 'MY' is a valid subclass name that
will get you access to the MakeMaker methods.
...you may define private subroutines in the Makefile.PL
^^
Docs aren't perfect, but I can't possibly see how the
Overriding MakeMaker
Methods docs gives license to do:
my $MM = bless {} = 'MY';
...
my($extralibs, $bsloadlibs, $ldloadlibs, $ld_run_path) =
$MM-ext(join ' ', -L$lpath, $libperl, potential_libs);
You don't just bless hashes directly into classes that might
vaguely exist
without some knowledge that you're doing naughty things.
That makes it sound so seedy. But there's no difference between
doing that and doing MY-ext(...), which doesn't sound as seedy
anymore.
The point is that the docs say that MY is a class that inherits
from ExtUtils::MakeMaker (or more precisely ExtUtils::MM_*), but
it doesn't say under what conditions, so one might reasonably
assume that it happens when you load ExtUtils::MakeMaker. This
was true (more or less) for a long time, then not true for a
while, and now it's true again.
That code was likely written years and years ago anyway.
Yes, you'll certainly get no argument from me that it Should Be Changed.
-Ken
Re: Makefile.PL's in subdirs affect each other and their parent
On Thursday, April 25, 2002, at 01:45 PM, Stas Bekman wrote: What about adding a new flag? e.g. if the main Makefile.PL says: WriteMakefile( PrivateCompartment = 1, ... ) then it'll provide one and all children will inherit it unless they explicitly override it? It's difficult to add new flags to MakeMaker, because you have to ensure that all the people installing your module have a version of MakeMaker that supports it. Perhaps difficult isn't the right word - more like futile. If you don't mind putting a MakeMaker dependency in the distribution, though, it can be done. Really, it would be nice to have separate build_dependency items, like a real package manager. Stas, for your problem, a really ugly but workable solution might be to fork the main process in each of the subdirs' Makefile.PL's, oder? -Ken
MY Errors on compiling mod_perl
Hey,
I'm on OS X 10.1.4, perl 5.6.0, using the blead-Makemaker at the
time of this writing. I'm trying to compile mod_perl 1.26 with
apache 1.3.22.
I used to be able to just do perl Makefile.PL EVERYTHING=1.
However, now I get errors like the following (note the q{Can't
locate object method catdir via package MY}). Something
changed here?
==
=== modules/perl
=== modules
cc -c -I./os/unix -I./include -DDARWIN -DUSE_HSREGEX
-DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -pipe -fno-common
-DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing
-I/System/Library/Perl/darwin/CORE -I. -I../.. -DUSE_PERL_SSI
-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing
-DMOD_PERL modules.c
cc -c -I./os/unix -I./include -DDARWIN -DUSE_HSREGEX
-DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -pipe -fno-common
-DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing
-I/System/Library/Perl/darwin/CORE -I. -I../.. -DUSE_PERL_SSI
-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing
-DMOD_PERL buildmark.c
cc -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite
-DNO_DL_NEEDED -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE
-fno-strict-aliasing -I/System/Library/Perl/darwin/CORE -I.
-I../.. -DUSE_PERL_SSI -pipe -fno-common
-DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -DMOD_PERL\
-o httpd buildmark.o modules.o modules/perl/libperl.a
modules/proxy/libproxy.a modules/standard/libstandard.a
main/libmain.a ./os/unix/libos.a ap/libap.a regex/libregex.a
lib/expat-lite/libexpat.a `perl
/Users/ken/Downloads/perl/mod_perl-1.26/src/modules/perl/ldopts `
Can't locate object method catdir via package MY (perhaps
you forgot to load MY?) at
/System/Library/Perl/ExtUtils/Embed.pm line 185.
/usr/bin/ld: warning multiple definitions of symbol _regcomp
regex/libregex.a(regcomp.o) private external definition of
_regcomp in section (__TEXT,__text)
/usr/lib/libSystem.dylib(regcomp.o) definition of _regcomp
/usr/bin/ld: warning multiple definitions of symbol _regexec
regex/libregex.a(regexec.o) private external definition of
_regexec in section (__TEXT,__text)
/usr/lib/libSystem.dylib(regexec.o) definition of _regexec
/usr/bin/ld: warning multiple definitions of symbol _regfree
regex/libregex.a(regfree.o) private external definition of
_regfree in section (__TEXT,__text)
/usr/lib/libSystem.dylib(regfree.o) definition of _regfree
/usr/bin/ld: Undefined symbols:
_PL_endav
_PL_envgv
_PL_errgv
_PL_incgv
_PL_markstack_max
_PL_markstack_ptr
_PL_na
_PL_patchlevel
_PL_perl_destruct_level
_PL_stack_base
_PL_stack_max
_PL_stack_sp
_PL_sv_undef
_PL_tainted
_PL_tainting
_PL_tmps_floor
_PL_tmps_ix
_PL_warnhook
_Perl_av_clear
_Perl_av_fetch
_Perl_av_len
_Perl_av_make
_Perl_av_push
_Perl_av_undef
_Perl_croak
_Perl_form
_Perl_free_tmps
_Perl_gv_fetchmethod
_Perl_gv_fetchpv
_Perl_gv_stashpv
_Perl_hv_clear
_Perl_hv_exists
_Perl_hv_fetch
_Perl_hv_store
_Perl_hv_undef
_Perl_markstack_grow
_Perl_mg_size
_Perl_my_setenv
_Perl_newAV
_Perl_newHV
_Perl_newRV_noinc
_Perl_newSV
_Perl_newSVpv
_Perl_newSVsv
_Perl_pop_scope
_Perl_push_scope
_Perl_rsignal
_Perl_save_aptr
_Perl_save_hptr
_Perl_save_int
_Perl_save_sptr
_Perl_stack_grow
_Perl_sv_2bool
_Perl_sv_2cv
_Perl_sv_2iv
_Perl_sv_2mortal
_Perl_sv_2pv
_Perl_sv_catpv
_Perl_sv_dump
_Perl_sv_free
_Perl_sv_isobject
_Perl_sv_newmortal
_Perl_sv_setiv
_Perl_sv_setpv
_Perl_sv_setpvf
_Perl_sv_setpvn
_Perl_sv_setref_pv
_Perl_sv_setsv
_Perl_sv_taint
_Perl_sv_unmagic
_Perl_warn
_perl_alloc
_perl_call_method
_perl_call_sv
_perl_construct
_perl_destruct
_perl_eval_pv
_perl_free
_perl_get_av
_perl_get_cv
_perl_get_sv
_perl_init_i18nl10n
_perl_parse
_perl_run
_PL_curstash
_PL_dowarn
_PL_sv_yes
_Perl_av_shift
_Perl_cv_undef
_Perl_gv_fetchmethod_autoload
_Perl_hv_delete
_Perl_hv_delete_ent
_Perl_hv_exists_ent
_Perl_hv_iterinit
_Perl_hv_iternextsv
_Perl_mg_get
_Perl_rsignal_state
_Perl_sv_bless
_Perl_sv_catpvf
_Perl_sv_catpvn
_Perl_sv_catsv
_Perl_sv_magic
_Perl_whichsig
_perl_eval_sv
_perl_get_hv
_PL_beginav
_PL_curcop
_PL_defstash
_PL_diehook
_PL_egid
_PL_euid
_PL_gid
_PL_rs
_PL_scopestack_ix
_PL_sv_no
_PL_uid
_Perl_av_extend
_Perl_av_store
_Perl_call_list
_Perl_hv_fetch_ent
_Perl_hv_iternext
_Perl_instr
_Perl_mg_find
_Perl_mg_set
_Perl_newGVgen
_Perl_newRV
_Perl_save_item
_Perl_sv_derived_from
_Perl_sv_gets
_perl_require_pv
_PL_defoutgv
_Perl_newXS
_boot_DynaLoader
_PL_curpad
_PL_laststatval
_PL_op
_PL_statcache
_PL_statname
_Perl_block_gimme
_Perl_do_join
_Perl_do_open
_Perl_dowantarray
_Perl_newSViv
_Perl_sv_2io
_Perl_sv_grow
_Perl_sv_setnv
_Perl_sv_setuv
_Perl_sv_upgrade
_perl_call_pv
_Perl_gv_stashpvn
_Perl_newCONSTSUB
_Perl_do_close
_Perl_sv_2nv
_Perl_sv_isa
_Perl_safefree
_Perl_safemalloc
_Perl_sv_2uv
/usr/bin/ld: warning unused multiple definitions of symbol _regerror
regex/libregex.a(regerror.o) definition of _regerror in section
(__TEXT,__text)
/usr/lib/libSystem.dylib(regerror.o) unused definition of _regerror
make[1]: ***
Re: Bizarre: MakeMaker won't install itself
On Monday, April 22, 2002, at 02:47 PM, Michael G Schwern wrote: record type=brokenCan I see your Makefile?/record From what you say on IRC it sounds like you don't need it after all, but for thread completion here's a relevant excerpt: = # --- MakeMaker constants section: AR_STATIC_ARGS = cr NAME = ExtUtils::MakeMaker DISTNAME = ExtUtils-MakeMaker NAME_SYM = ExtUtils_MakeMaker VERSION = 5.90_01 VERSION_SYM = 5_90_01 XS_VERSION = 5.90_01 INST_ARCHLIB = blib/arch INST_SCRIPT = blib/script INST_BIN = blib/bin INST_LIB = blib/lib INSTALLDIRS = perl PREFIX = /usr SITEPREFIX = /usr/local VENDORPREFIX = /usr/local INSTALLPRIVLIB = $(PREFIX)/lib/perl5 INSTALLSITELIB = $(SITEPREFIX)/lib/perl5/site_perl INSTALLVENDORLIB = $(VENDORPREFIX)/lib/perl5 INSTALLARCHLIB = $(PREFIX)/lib/perl5/5.6.1/darwin INSTALLSITEARCH = $(SITEPREFIX)/lib/perl5/site_perl/5.6.1/darwin INSTALLVENDORARCH = $(VENDORPREFIX)/lib/perl5/5.6.1/darwin INSTALLBIN = $(PREFIX)/bin INSTALLSITEBIN = $(SITEPREFIX)/bin INSTALLVENDORBIN = $(VENDORPREFIX)/bin INSTALLSCRIPT = $(PREFIX)/bin PERL_LIB = /System/Library/Perl PERL_ARCHLIB = /System/Library/Perl/darwin SITELIBEXP = /Library/Perl SITEARCHEXP = /Library/Perl/darwin LIBPERL_A = libperl.a FIRST_MAKEFILE = Makefile MAKE_APERL_FILE = Makefile.aperl PERLMAINCC = $(CC) PERL_INC = /System/Library/Perl/darwin/CORE PERL = /usr/bin/perl = -Ken
