module-build-general Mailing List for Module::Build (Page 146)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-18 01:49:13
|
On 12/17/2003 9:25 AM, Ken Williams wrote: > (A snapshot just because it's been so long since anything has been > released) oops, Version <none> of what? $ perl Build.PL Checking whether your kit is complete... Looks good * Version <none> is installed, but we prefer to have 0.35 * Version <none> is installed, but we prefer to have 2.02 ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions of the modules indicated above before proceeding with this installation. Everything else looks good on Windows and Cygwin. I still haven't found time to look into CBuilder yet with the chaotic Christmas season going on. Hopefully, I'll have a chance by this weekend to atleast get it working on Windows. Regards, Randy. |
|
From: Ken W. <ke...@ma...> - 2003-12-17 14:25:39
|
http://sourceforge.net/project/ showfiles.php?group_id=45731&release_id=204435 or eventually: http://search.cpan.org/~kwilliams/Module-Build-0.21_01/ 0.21_01 Wed Dec 17 07:51:49 CST 2003 (A snapshot just because it's been so long since anything has been released) - Fixed a have_c_compiler() failure on some platforms, we now define a boot_compilet() function (since we're compiling a library, not an executable). [Randy Sims] - Added a recipe to the Module::Build::Cookbook describing how to maintain compatibility with older versions of CPAN.pm [Jim Cromie] - Removed caveat about "looking for alternatives" in how hashes are specified on the command line, since an alternative has been found. - Previously most warnings about optional prerequisites looked like they were actually error messages about required prerequisites. This has been corrected. [Reported again by Sagar Shah] - Added support for building XS (and C in general) stuff on AIX. This was done by a small reorganization of prelink_c() method from Windows.pm to Build.pm, and it is only invoked for the platforms that need it invoked. AIX also massages some very naughty bits in $Config{lddlflags} that should never have been put there, but alas, they're there. - Added OS/2 ($^O = 'os2') to the list of Unix-like platforms. This basically means that most platform-specific operations will be done in a Unix-like manner. - Pass-through Makefiles will now die() when they're given a PREFIX parameter, and suggest using 'destdir' or 'install_base' instead. Previously they just ignored the parameter and tried to install to the default location, which is clearly not what the user wanted. - Updated my email address in the documentation to a more recent variant. - On some platforms it's common to have a $Config{make} defined, but no 'make' utility available. We now detect this and skip some 'make' compatibility tests. [Randy Sims] - Add NetBSD to the list of Unix-like systems. [Adrian Bunk] - Add SVR5 to the list of Unix-like systems. [Rafael Garcia-Suarez] - Fixed a spurious testing failure on non-Unix platforms that happened because we accidentally call localize_file_path() on empty strings in the test suite. [Spotted by Randy Sims on Windows] - Fixed a problem with creating the distribution tarball in which permissions would usually be all read-only. We now use our own file-copying routines rather than those in ExtUtils::Manifest, because those do some annoying extra permissions-setting stuff for no apparent reason. It makes me happy that this was a very very easy patch to make. [Reported by Thomas Klausner] - The compile_c() method now includes $Config{cccdlflags} in its command invocation. It's usually empty, but not always, so we didn't notice for a while. [Richard Clamp] - The have_c_compiler() now also tests whether the linker seems to work too. - On Unixish platforms, the syntax "FOO=BAR /bin/baz arg arg" now works when present in $Config{ld}. This solves a problem on Mac OS X 10.3. [Reported by Adam Foxson] - We now use Pod::Parser to find the ABSTRACT and AUTHOR when it's available on the system. [initial patch by Randy Sims] - Fixed a little scalar/list buglet in a documentation example. |
|
From: Sagar S. <sag...@so...> - 2003-12-15 21:35:22
|
On Wed, 2003-12-03 at 06:31, Michael G Schwern wrote: > On Fri, Nov 28, 2003 at 03:13:32PM -0600, Ken Williams wrote: > > >One problem that i've found is that when generating the MANIFEST > > >Module::Build doesn't add the README to it, and so it doesn't actually > > >get includede in the dist tarball... > > > > > >Bug? > >=20 > > I'm reluctant to add things automatically to the MANIFEST, because in=20 > > general I don't want to surprise the user about things. With the=20 > > SIGNATURE file there's a chicken-egg problem that can only be solved by= =20 > > adding it to the MANIFEST automatically, but with the README I think=20 > > the author should just add it him/herself. >=20 > I dunno. It seems that the Principle of Least Surprise would say that > if you created a README automaticly, you'd want it distributed. Since > there's little indication to the author that the README is *not* getting > distributed, I'd say the common bug will be an author that sets > create_readme and then forgets to add it to the MANIFEST. Not the author > that turns on create_readme and doesn't want it in the MANIFEST. Ken, I agree with Michael's comments, but the use case where i hit this was where I don't even have a MANIFEST. I just use a MANIFEST.SKIP and have M::B create my MANIFEST for me.=20 So you see, i cannot add README to the MANIFEST because i don't have a self made MANIFEST. create_readme doesn't cause the README to be created before the MANIFEST is generated. So perhaps if you don't want create_readme to explicty insert README into MANIFEST, perhaps you can change the ordering of the actions slightly?=20 That way users who do have a MANIFEST will not get surprised by extra additions. Whereas users with no MANIFEST, will 'get the right manifest'. Warming to the idea @ all? Cheers Sagar --=20 Sagar Shah <sag...@so...> |
|
From: Ken W. <ke...@ma...> - 2003-12-10 02:25:03
|
On Tuesday, December 9, 2003, at 03:04 PM, Jim Cromie wrote: > > 1. a recipe about Module::Build::Compat, and its support for 'cpan> > install Foo' > 2. a Pod nit: disambiguate a sentence: s/this/the compilation/ Excellent, I'll apply them both (the first with an additional sentence about the 'create_makefile_pl' parameter). Thanks! -Ken |
|
From: Jim C. <jc...@di...> - 2003-12-09 21:04:06
|
1. a recipe about Module::Build::Compat, and its support for 'cpan> install Foo' 2. a Pod nit: disambiguate a sentence: s/this/the compilation/ |
|
From: Ken W. <ke...@ma...> - 2003-12-09 03:21:43
|
On Monday, December 8, 2003, at 01:40 PM, Randy W. Sims wrote: > > Just curious, but why does CPANPLUS need a list of all prereqs and not > just the failed ones? It would be nice if we could just tell CPANPLUS the failures, because then CPANPLUS wouldn't have to know how to parse the version dependency specifications. > And in what way are the dispatch methods not working properly? I > didn't see this explained in previous messages. I think it's just that new_from_context() doesn't have a stable name yet, right Jos? I think that if nobody can think of a more appropriate name, we should just ratify the current one. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-08 19:40:45
|
On 12/8/2003 8:58 AM, Jos I. Boumans wrote: > > On 12-sep-03, at 20:19, Ken Williams wrote: > >> On Friday, September 12, 2003, at 09:35 AM, Jos I. Boumans wrote: >> >>> >>> * Is there a nicer way to get the prereqs out of the $m object, >>> rather than poking into it? >> >> >> Try the prereq_failures() method - or do you need more than just the >> unfulfilled prereqs? > > > just a reminder -- for proper integration with the cpanplus build > process, i need the dispatch methods to work properly, as well as a full > listing of prereqs (not just the failed ones). > > I've mentioned this already some time ago, but then radio silence > occurred... > Just curious, but why does CPANPLUS need a list of all prereqs and not just the failed ones? And in what way are the dispatch methods not working properly? I didn't see this explained in previous messages. Thanks, Randy. |
|
From: Jos I. B. <ka...@xs...> - 2003-12-08 13:58:27
|
On 12-sep-03, at 20:19, Ken Williams wrote: > On Friday, September 12, 2003, at 09:35 AM, Jos I. Boumans wrote: >> >> * Is there a nicer way to get the prereqs out of the $m object, >> rather than poking into it? > > Try the prereq_failures() method - or do you need more than just the > unfulfilled prereqs? just a reminder -- for proper integration with the cpanplus build process, i need the dispatch methods to work properly, as well as a full listing of prereqs (not just the failed ones). I've mentioned this already some time ago, but then radio silence occurred... -- Jos Boumans "We are not far from the kind of moral decay that has brought on the fall of other nations and peoples" - Senator Barry Goldwater, 1964 CPANPLUS http://cpanplus.sf.net |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-06 15:36:42
|
Resending: this never made it to the list. (originally sent 12/4/2003 9:06 PM) On 12/3/2003 11:01 PM, Ken Williams wrote: > Also, have you had a chance to take a look at ExtUtils::CBuilder? How > do you see it fitting in with a plugin scheme? My goal with it was to > make something that would be generically useful, not just as a plugin > for Module::Build. I've /briefly/ looked at EU::CBuilder (btw, there is a product, a compiler with that name <http://www.borland.com/cbuilderx/>). Lifting that code out of M::B should make things much easier to manage. It is going to need to change a good bit... mostly just parameterizing on whether creating a static or dynamic library (or executable?) and on whether or not to include all the perl defines, etc. The reason for the latter is modules like Compress::Zlib that includes the source for and build zlib and links to it. zlib would not need to see any of the perl specific stuff. As far as fitting in with the plugin scheme, I haven't tried to look far enough to be able to nail down an interface between the two. I'm mostly looking from the top-down. I'm imagining that there will be some action builders that make it easy to construct actions to accomplish certain goals. The relevant builder here would be the library builder which would be given a list of source files, and it would then create all the neccessary actions and dependencies. my $lib = Module::Build::Action::Builder->new_library( output => 'mylib', sources => [ qw(file1.c file2.c file3.c) ], use_perl => 1, # include perl specific stuff ); Under the hood it would create an action named 'mylib', generate depenecies on the object files, create actions for each of the object files with a dependency on its respective source file, etc. Then you would say Module::Build::Action::by_name('code')->add_dependency($lib); to add it as a dependency of the code action. This design resulted in my decision to implement the prototype the way I did. Specifically scanning for plugins at startup to generate a list of action which can then be modified at runtime. Scanning at startup initially had me concered because of a delayed startup, but testing on an old 466 Mhz pentium has nearly convinced me that it won't be a problem. As far as how the above will interface with EU::CBuilder, I'm not entirely sure yet. I'm hoping it will be obvious when we get there. =) Randy. He He, this interesting(?) article just showed up on <http://news.google.com/>: <http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2003/12/05/nfossil05.xml&sSheet=/portal/2003/12/05/ixportal.html> |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-06 15:29:23
|
On 12/3/2003 11:01 PM, Ken Williams wrote:
>
> Also, have you had a chance to take a look at ExtUtils::CBuilder? How
> do you see it fitting in with a plugin scheme? My goal with it was to
> make something that would be generically useful, not just as a plugin
> for Module::Build.
>
I've been thinking a little more about EU::CBuilder. I've come up with
the following list of tasks that it must be able to accomplish as far as
providing services to M::B. Do you see anything missing or extraneous?
* determine if compiler/linker are present and configured.
* preprocess XS files to c/c++ source files.
* (optionally) run the c/c++ source files through the cpp preprocessor
and output the results for debugging help.
* compile the c/c++ source files for use in a perl dynamic library.
(what it does now)
* compile the c/c++ source files for use in a statically linked in
library (main differentiator here is the exclusion of
$Config{cccdlflags} when compiling).
* compile the c/c++ source files for use in a non-perl library (in this
case we don't need to know if it's for a static or dynamic library).
* generate symbolic export definition file for the library if it's a
perl dynamic library (prelink).
* link object files into a perl dynamic library.
* link object files into a non-perl dynamic library.
* link object files into a static library and then link with perl
(makeaperl).
* link object files into a non-perl static library. (ex. Compress::Zlib)
* link object files into an executable.
* track temporaries and output files.
(It's kinda neat working with a (new pet) ferret running around on the
desk except when she starts playing with the (non-pet) mouse while I'm
trying to type. Oh, and she also has this annoying habbit of taking a
dump on the corner of the desk which isn't so bad as far as cleaning up,
but the dang thang won't lick herself. I don't know what to think of an
animal that want lick itself clean after going to the pot. I don't won't
to pick her up and get... stuff all over me... ick.)
Regards,
Randy.
PS: There seems to be something wrong with the list--missing messages,
archives out of sync, etc. Is this a sourceforge problem?
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-05 00:21:53
|
On 12/4/2003 3:50 PM, Stas Bekman wrote: > Randy, > > I've a question regarding the 'requires' tag. > > For example, we have Apache::* modules. Some of them can run only under > mod_perl 1.0, others only under mod_perl 2.0, and there are those who > can run with both generations. The 'requires' tag in your proposal says: > > I<Note: The exact nature of the fancy specifications like > S<C<E<gt>= 1.2, != 1.5, E<lt> 2.0>> is subject to change. Advance > notice will be given here. The simple specifications like C<1.2> > will not change in format.> > > Can this be finalized? Or is it an issue with EU::MM and M::B needing to > agree on the advanced syntax of PREREQ_PM? > > We need at least these cases: > > # any > requires: > mod_perl: 1.01 > > # only mp1 > requires: > mod_perl: < 1.99 > > # only mp2 > requires: > mod_perl: >= 1.99 > IIRC, there was some discussion at some point... ok, right here <http://sourceforge.net/mailarchive/forum.php?thread_id=1676522&forum_id=10905>. I think Ken was considering other alternatives, so the above was never finalized. I think he's on these lists, but I'll cc him and let him respond. -- Hmm, I also find in this thread something similar to my proposal for optional_features suggested by Autrijus. I missed that before. And in searching I see I also missed this thread <http://sourceforge.net/mailarchive/forum.php?thread_id=1790056&forum_id=10905>. Where the provides field was first documented. There is some duplication in this and the no_index proposal. I guess I wasn't as thorough as I thought. :( Randy. It would be nice if the module-build ML were on <nntp.perl.org> and archived at <http://nntp.x.perl.org/group/>. |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-04 19:13:38
|
On 12/3/2003 11:01 PM, Ken Williams wrote: > Hi Randy, > > I'm not trying to ignore you, I swear - I just keep wanting to make a > little prototype of what I had in mind for a plugin architecture too, > and I thought it might be better to do it independently first and then > we can compare advantages & disadvantages of each. No problem. I guess some people do have a life outside of writing code ;). > Several of the points below are advantages of any plugin scheme we > settle on, and I'm still quite keen on getting *something* done. If I > can't get off (or on, I guess) my butt and write some code of my own, my Yeah, I don't claim my solution is the best. In fact, it's really not much like what I originally planned; it evolved quite a bit into what it is now. Like I said before, I'm mainly thinking about the compiling/linking code, and I see plugins as an elegant solution to the current problems... > default action will be to just apply your patches. Please don't apply my patch; it's still a prototype, and I need to clean it up a bit. I need to reorganize it by splitting M::B::Action, so that M::B::Action remains a base class, and the other /stuff/ gets put into something like M::B::ActionManager which will be responsible for scanning plugins and dispatching actions. > I do very much appreciate the time you've spent. > > Also, have you had a chance to take a look at ExtUtils::CBuilder? How > do you see it fitting in with a plugin scheme? My goal with it was to > make something that would be generically useful, not just as a plugin > for Module::Build. I will try to post something this evening when I have more time to put my thoughts together into something coherent. =) Regards, Randy. |
|
From: Ken W. <ke...@ma...> - 2003-12-04 04:01:44
|
On Tuesday, December 2, 2003, at 06:18 PM, Randy W. Sims wrote: > On 11/30/2003 9:15 AM, Randy W. Sims wrote: >> This is a prototype and contains some no no's, but it hopefully >> provides enough to comment on. This is about as far as I can go >> without being invasive, and I wanted to get feedback before before >> proceeding. It is a prototype, so if you think it should be thrown >> out, that's fine. Otherwise, I'll start cleaning it up and either >> turn it over to you if you want, or continue (I'm a little reluctant >> to do something as invasive as this will be and create the plugin >> API, but I'm more than willing to help:). >> Hope this is helpfull. >> Randy. > > > Well, no one is commenting. That's not good. Hi Randy, I'm not trying to ignore you, I swear - I just keep wanting to make a little prototype of what I had in mind for a plugin architecture too, and I thought it might be better to do it independently first and then we can compare advantages & disadvantages of each. Several of the points below are advantages of any plugin scheme we settle on, and I'm still quite keen on getting *something* done. If I can't get off (or on, I guess) my butt and write some code of my own, my default action will be to just apply your patches. I do very much appreciate the time you've spent. Also, have you had a chance to take a look at ExtUtils::CBuilder? How do you see it fitting in with a plugin scheme? My goal with it was to make something that would be generically useful, not just as a plugin for Module::Build. > Perhaps I should list > some of the benefits of this plugin architecture: > > * Users can write and distribute their own custom actions. > > * Module authors can simplify their Build.PL files by writing their > custom actions as plugins, placing them in > 'inc/Module/Build/Action/' and adding a 'use lib qw(inc);' before > they > 'use Module::Build'. > > * Sites can customize installs in a similar manner as above by setting > the PERL5LIB environment variable to point to their custom overrides > of builtin actions. > > * Action builders can make it extremely easy to create simple > actions. > > * Allows for an elegant solution to the current architectural issues > regarding compiling/linking in Module::Build. (This is my primary > goal in creating this prototype.) > > * Simplifies Module::Build, providing better encapsulation for its > different functional areas. > > Ken, should I drop this? I would like to help where I can. M::B is a > project I believe very strongly in, but someone needs to tell me where > (or if) I can help. > > I've got a short list of things I'd like to contribute: plugins, > compiler stuff, adding trace info (like make --debug), nested builds, > h2xs M::B support, support for building modules outside the source > directory. But this is your project, and I don't want to get in the > way. Just tell me where to go. ;) > > Regards, > Randy. > |
|
From: Ken W. <ke...@ma...> - 2003-12-04 03:51:01
|
Version 0.00_02 of ExtUtils::CBuilder is now on CPAN. It adds support
for all platforms except for Windows - there's a lot of code to
integrate for Windows so I'm saving it for last.
The uploaded file
ExtUtils-CBuilder-0.00_02.tar.gz
has entered CPAN as
file: $CPAN/authors/id/K/KW/KWILLIAMS/ExtUtils-CBuilder-0.00_02.tar.gz
size: 7536 bytes
md5: 12da14d3e7bdbc03e84d53f4eb6dfc00
-Ken
|
|
From: Michael G S. <sc...@po...> - 2003-12-03 06:31:55
|
On Fri, Nov 28, 2003 at 03:13:32PM -0600, Ken Williams wrote: > >One problem that i've found is that when generating the MANIFEST > >Module::Build doesn't add the README to it, and so it doesn't actually > >get includede in the dist tarball... > > > >Bug? > > I'm reluctant to add things automatically to the MANIFEST, because in > general I don't want to surprise the user about things. With the > SIGNATURE file there's a chicken-egg problem that can only be solved by > adding it to the MANIFEST automatically, but with the README I think > the author should just add it him/herself. I dunno. It seems that the Principle of Least Surprise would say that if you created a README automaticly, you'd want it distributed. Since there's little indication to the author that the README is *not* getting distributed, I'd say the common bug will be an author that sets create_readme and then forgets to add it to the MANIFEST. Not the author that turns on create_readme and doesn't want it in the MANIFEST. -- Michael G Schwern sc...@po... http://www.pobox.com/~schwern/ We don't know. But if we did, we wouldn't tell you. |
|
From: Randy W. S. <Ra...@Th...> - 2003-12-03 00:18:22
|
On 11/30/2003 9:15 AM, Randy W. Sims wrote: > > This is a prototype and contains some no no's, but it hopefully provides > enough to comment on. This is about as far as I can go without being > invasive, and I wanted to get feedback before before proceeding. It is a > prototype, so if you think it should be thrown out, that's fine. > Otherwise, I'll start cleaning it up and either turn it over to you if > you want, or continue (I'm a little reluctant to do something as > invasive as this will be and create the plugin API, but I'm more than > willing to help:). > > Hope this is helpfull. > > Randy. Well, no one is commenting. That's not good. Perhaps I should list some of the benefits of this plugin architecture: * Users can write and distribute their own custom actions. * Module authors can simplify their Build.PL files by writing their custom actions as plugins, placing them in 'inc/Module/Build/Action/' and adding a 'use lib qw(inc);' before they 'use Module::Build'. * Sites can customize installs in a similar manner as above by setting the PERL5LIB environment variable to point to their custom overrides of builtin actions. * Action builders can make it extremely easy to create simple actions. * Allows for an elegant solution to the current architectural issues regarding compiling/linking in Module::Build. (This is my primary goal in creating this prototype.) * Simplifies Module::Build, providing better encapsulation for its different functional areas. Ken, should I drop this? I would like to help where I can. M::B is a project I believe very strongly in, but someone needs to tell me where (or if) I can help. I've got a short list of things I'd like to contribute: plugins, compiler stuff, adding trace info (like make --debug), nested builds, h2xs M::B support, support for building modules outside the source directory. But this is your project, and I don't want to get in the way. Just tell me where to go. ;) Regards, Randy. |
|
From: Ken W. <ke...@ma...> - 2003-12-02 04:17:06
|
Hi,
I've just released a pre-beta of ExtUtils::CBuilder:
The uploaded file
ExtUtils-CBuilder-0.00_01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/K/KW/KWILLIAMS/ExtUtils-CBuilder-0.00_01.tar.gz
size: 5858 bytes
md5: fcec1cccb088d34bc45fe5b374b6639c
It's intended to take all the c-compilation code out of Module::Build
and stick it in a general-purpose c-compilation-for-perl-modules module.
Next, I (or another kind soul with tuits to spare) will add the various
overridden code in the compile_c() and link_c() stuff from
Module::Build::Platform::* classes.
-Ken
|
|
From: Jim C. <jc...@di...> - 2003-12-01 00:17:48
|
Nicholas Clark wrote:
>On Fri, Nov 28, 2003 at 05:51:16PM -0700, Jim Cromie wrote:
>
>
Following up on this thread I started, P5P has discussions today which
appear to explain this;
xsubpp is now installed into bin not lib, so a box with multiple
versions can get fouled up.
I havent yet proven that this is my problem, but it sounds right.
Subject: xsubpp is not installed.
thanks Nick
>>sub find_perl_interpreter {
>> my $perl;
>> File::Spec->file_name_is_absolute($perl = $^X)
>>- or -f ($perl = $Config::Config{perlpath})
>>- or ($perl = $^X);
>>+ or ($perl = $^X)
>>
>>
>
> ^^ that will always be true (unless perl is named "0" and . is in
>your PATH)
>
>
>
>>+ or -f ($perl = $Config::Config{perlpath});
>>
>>
>
>hence this will never be reached
>
>
I think thats the point - to set $perl one way or the other.
preferring an absolute path form of $^X, or %Configs notion, or just $^X.
>
>
>>perl -V
>>
>>WAG. Is @INC pointing to the right places.
>>
>>
>
>Inline had what seemed to be the same problem. It occurs when you
>install (say) 5.6.1, and it "knows" that it is /usr/local/bin/perl
>(ie
>/usr/local/bin/perl5.6.1 -MConfig -le 'print $Config::Config{perlpath}'
>will give that.)
>
>Later you install 5.8.2 in /usr/local/bin. /usr/local/bin/perl is now
>a hard link to /usr/local/bin/perl5.8.2
>and its Config thinks (correctly) that it is /usr/local/bin/perl
>However, 5.6.1 is still available as /usr/local/bin/perl5.6.1, and so:
>
>$ /usr/local/bin/perl5.6.1 -MConfig -le 'print $Config::Config{perlpath}'
>/usr/local/bin/perl
>
>So if you explictly run your script as /usr/local/bin/perl5.6.1 Build.PL
>$^X points to the right thing, but $Config::Config{perlpath} no longer does.
>
>If this is the same problem, offhand I can't remember the best way to solve
>it. Pinch the code from Inline :-)
>
>Nicholas Clark
>
>
>
|
|
From: Randy W. S. <Ra...@Th...> - 2003-11-30 17:28:18
|
As I work on this, I'll keep updated versions at <http://www.thepierianspring.org/patch.gz>. Randy. |
|
From: Randy W. S. <Ra...@Th...> - 2003-11-30 14:15:53
|
Hi Ken,
Attached is a /prototype/ (about the 3rd one) for plugin actions. In the
prototype all plugin action names are prefixed with an 'x' so that they
don't override the current actions. The only actions implemented are
'xhelp' and 'xmanifest', though templates are inplace for the others.
See perldoc lib/Module/Build/Action.pm for an extremely brief user view
of creating plugins.
The only things worth looking at right now are Module::Build::Action and
Module::Build::Action::Help. M::B::Action builds up a list of plugins
and some info about them. We highjack the dispatch call in M::B::Base to
our own in M::B::Action which looks up dependencies and executes them
recursively. This is of course different than the
M::B::Base::depends_on() immediate execution method of handling
dependencies, but it is more flexible and will allow builders (modules
that aid in creating new actions) to work. When we highjack the dispatch
call we also pass in $self->{args} so that actions can process thier own
arguments.
This is a prototype and contains some no no's, but it hopefully provides
enough to comment on. This is about as far as I can go without being
invasive, and I wanted to get feedback before before proceeding. It is a
prototype, so if you think it should be thrown out, that's fine.
Otherwise, I'll start cleaning it up and either turn it over to you if
you want, or continue (I'm a little reluctant to do something as
invasive as this will be and create the plugin API, but I'm more than
willing to help:).
Hope this is helpfull.
Randy.
|
|
From: Randy W. S. <Ra...@Th...> - 2003-11-29 17:06:59
|
On 11/29/2003 11:58 AM, Ken Williams wrote:
>
> On Saturday, November 29, 2003, at 10:48 AM, Randy W. Sims wrote:
>
>>
>> The problem is that the code in compile_c() and link_c(), on Windows
>> specifically, but also M::B in general, is written to produce a
>> dynamic perl module library. In Windows land an executable requires a
>> different set of flags, etc to produce an executable file. So, instead
>> of writting a lot of new scaffolding to compile an executable for the
>> three different compilers on Windows, the patch basically adds enough
>> to complete a minimal, skeletal, perl library. Without the
>> boot_compilet() function, the linker would report an undefined
>> reference to external symbol or something like.
>
>
> Oh, I see. I guess I could actually take out the main() function too
> then, right? It's not used anywhere.
>
> -Ken
Yeah, something like the following passes:
print $fh "boot_compilet() { return 1; }";
|
|
From: Ken W. <ke...@ma...> - 2003-11-29 16:58:15
|
On Saturday, November 29, 2003, at 10:48 AM, Randy W. Sims wrote: > > The problem is that the code in compile_c() and link_c(), on Windows > specifically, but also M::B in general, is written to produce a > dynamic perl module library. In Windows land an executable requires a > different set of flags, etc to produce an executable file. So, instead > of writting a lot of new scaffolding to compile an executable for the > three different compilers on Windows, the patch basically adds enough > to complete a minimal, skeletal, perl library. Without the > boot_compilet() function, the linker would report an undefined > reference to external symbol or something like. Oh, I see. I guess I could actually take out the main() function too then, right? It's not used anywhere. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2003-11-29 16:48:30
|
On 11/29/2003 11:31 AM, Ken Williams wrote: > > I'm not sure I understand the patch, though. It seems to just create a > boot_compilet() C function, and make sure quotes are stripped from the > object filename. How does this fix the issue? > > -Ken The problem is that the code in compile_c() and link_c(), on Windows specifically, but also M::B in general, is written to produce a dynamic perl module library. In Windows land an executable requires a different set of flags, etc to produce an executable file. So, instead of writting a lot of new scaffolding to compile an executable for the three different compilers on Windows, the patch basically adds enough to complete a minimal, skeletal, perl library. Without the boot_compilet() function, the linker would report an undefined reference to external symbol or something like. I'm probably not explaining this well, but hopefully enough to make at least a little sense. Randy. |
|
From: Ken W. <ke...@ma...> - 2003-11-29 16:32:38
|
On Saturday, November 29, 2003, at 04:56 AM, Randy W. Sims wrote: > On 10/30/2003 9:36 PM, Randy W. Sims wrote: >> Hi Ken, >> Version 1.220 of M::B::Base.pm uncovered a bug. On Windows, an >> executable requires different options to the linker than a dynamic >> library. Currently link_c() is configured strictly to produce >> libraries. A quick and perhaps naive fix is to introduce an optional >> paramater to link_c() to indicate the desired type of the output >> file. But, I want to > > Here is a tmp patch to fix have_c_compiler(). This is to fullfill what > the prophet Ken spoke to Yves and all of module-authors saying: > > "This is actually an unfortunate bug in version 0.21 on Win32. Other > previous versions have worked fine, and I believe this specific issue > has already been fixed in CVS." Ah yes. I wonder if all prophecy can be explained by wishful thinking. =) [...] > > This is due to a problem in ExtUtils::ParseXS. EU::ParseXS generates > lines like the following in the 'C' file: > > #line 20 "lib\XSTest.c" > > The backslash/Win32 dir separator in that string should be translated > to a forward slash or double backslash. This is not a fatal error; > it's just an annoying warning. Aha, I'll have to fix that too then. I'm not sure I understand the patch, though. It seems to just create a boot_compilet() C function, and make sure quotes are stripped from the object filename. How does this fix the issue? -Ken |
|
From: Nicholas C. <ni...@cc...> - 2003-11-29 11:24:57
|
On Fri, Nov 28, 2003 at 05:51:16PM -0700, Jim Cromie wrote:
> sub find_perl_interpreter {
> my $perl;
> File::Spec->file_name_is_absolute($perl = $^X)
> - or -f ($perl = $Config::Config{perlpath})
> - or ($perl = $^X);
> + or ($perl = $^X)
^^ that will always be true (unless perl is named "0" and . is in
your PATH)
> + or -f ($perl = $Config::Config{perlpath});
hence this will never be reached
> perl -V
>
> WAG. Is @INC pointing to the right places.
Inline had what seemed to be the same problem. It occurs when you
install (say) 5.6.1, and it "knows" that it is /usr/local/bin/perl
(ie
/usr/local/bin/perl5.6.1 -MConfig -le 'print $Config::Config{perlpath}'
will give that.)
Later you install 5.8.2 in /usr/local/bin. /usr/local/bin/perl is now
a hard link to /usr/local/bin/perl5.8.2
and its Config thinks (correctly) that it is /usr/local/bin/perl
However, 5.6.1 is still available as /usr/local/bin/perl5.6.1, and so:
$ /usr/local/bin/perl5.6.1 -MConfig -le 'print $Config::Config{perlpath}'
/usr/local/bin/perl
So if you explictly run your script as /usr/local/bin/perl5.6.1 Build.PL
$^X points to the right thing, but $Config::Config{perlpath} no longer does.
If this is the same problem, offhand I can't remember the best way to solve
it. Pinch the code from Inline :-)
Nicholas Clark
|
7 messages has been excluded from this view by a project administrator.
