headers
Carsten Milling | 11 May 2004 21:02
Picon

[Module::Build] how to deal with special files in lib/

Hi,

I'm not sure if this is the right list for general help, since from
the archive it seems the discussion here is mostly about development
issues. If there is a better place place to ask my questions, please
let me know.

I have some files other than .pm or .pod in my lib/ tree (e.g. some
xsl stylesheets used by the module internally). I understand that by
default these don't get copied to blib/ and installed subsequently.
How am I supposed to customize my Build.PL (or a Module::Build
subclass for that matter) to get these files installed
properly. Shouldn't there be an easy way to achieve this? Maybe I'm
just blind, but I didn't find any hint in the Module::Build manpage
nor the CookBook.

Another thing I encountered is that file permissions are not preserved
when the distdir is created. I have some executable scripts in the
source tree which I would like to keep executable in the distribution
tarball. It's not a big deal, and I assume I could even replace the
scripts with custom build actions. But I'm too lazy/busy at the
moment ;)

Thanks for any suggestions.

Carsten Milling

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
(Continue reading)

Permalink | Reply | 7 comments |
headers
alan | 14 May 2004 18:29
Favicon

[Module::Build] _htmlify_pod vs. pm_files

I notice someone else recently described their problems with getting
ACTION_html to work correctly. Judging from their comments, it looks
like their approach to fixing things will probably address my issue too.
But for the sake of completeness: I'm having another problem with the
"html" target in Module::Build 0.25.

_htmlify_pod always sends "lib" as part of the --podpath argument to
pod2html. This causes ACTION_html to fail whenever the lib/ directory
doesn't exist. This is likely in cases where the pm_files configuration
is specified, to work with a non-standard directory layout (such as a
legacy MakeMaker layout).

I've hacked around this issue, so it's not bothering me anymore in
practice. Is the best way to shut off pod processing either to
specify "pod_files => {}" to turn off all doc processing, or to
remove the install_destination for the specific docs subsections you
don't want to build?

Thanks,

Alan

-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
Permalink | Reply | 2 comments |
headers
Jaap Karssenberg | 14 May 2004 21:07
X-Face
Picon
Picon

[Module::Build] Compat BUG

Although the Changes file reports differently, the Compat bug with the
including of a custom class is still there :( I reported this bug also
for the 0.24_01 version and I'm kind of disappointed that there is no
fix.

I think it is a good idea to have a subdir of _build, for example
"_build/custom", that isn't deleted at "./Build realclean" to store
custom build stuff. This would make the whole  <at> INC thing a lot easier
and more straight forward. Also,as I pointed out earlier, this would
have the advantage that indexers, like the pause indexer and the
search.cpan indexer, could know about it and ignore it.

--

-- 
   )   (     Jaap Karssenberg || Pardus [Larus]                | |0| |
   :   :     http://pardus-larus.student.utwente.nl/~pardus    | | |0|
 )  \ /  (                                                     |0|0|0|
 ",.*'*.,"   Proud owner of "Perl6 Essentials" 1st edition :)  wannabe

-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
Permalink | Reply | 7 comments |
headers
Ken Williams | 15 May 2004 00:44
Favicon

Re: [Module::Build] Compat BUG


On May 14, 2004, at 2:07 PM, Jaap Karssenberg wrote:

> Although the Changes file reports differently, the Compat bug with the
> including of a custom class is still there :( I reported this bug also
> for the 0.24_01 version and I'm kind of disappointed that there is no
> fix.

Maybe if you wrote a regression test that fails, I could fix it.  I've 
fixed every related problem I know about.

> I think it is a good idea to have a subdir of _build, for example
> "_build/custom", that isn't deleted at "./Build realclean" to store
> custom build stuff. This would make the whole  <at> INC thing a lot easier
> and more straight forward. Also,as I pointed out earlier, this would
> have the advantage that indexers, like the pause indexer and the
> search.cpan indexer, could know about it and ignore it.

The whole point of _build/ is that it *is* deleted at 'realclean' time, 
so I can put temporary files there and clean them up cleanly.  
Persistent stuff should go somewhere else.  A _build/ directory should 
never be part of a tarball uploaded to CPAN, so the indexer shouldn't 
have to know about it and ignore it.

  -Ken

-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ken Williams | 15 May 2004 00:52
Favicon

Re: [Module::Build] _htmlify_pod vs. pm_files


On May 14, 2004, at 11:29 AM, alan wrote:
> _htmlify_pod always sends "lib" as part of the --podpath argument to
> pod2html. This causes ACTION_html to fail whenever the lib/ directory
> doesn't exist. This is likely in cases where the pm_files configuration
> is specified, to work with a non-standard directory layout (such as a
> legacy MakeMaker layout).

I'm not all that familiar with all the arguments pod2html() wants - can 
you suggest a better value than "lib" when the code isn't in lib/ ?  
Then I might be able to arrange for it to be sent.

Or maybe I just do something like

    -d 'lib' ? ('--podpath' => 'lib') : ()

  -Ken

-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
Permalink | Reply | 1 comment |
headers
Jaap Karssenberg | 15 May 2004 12:13
X-Face
Picon
Picon

Re: [Module::Build] Compat BUG

On Fri, 14 May 2004 17:44:56 -0500 Ken Williams wrote:
: Maybe if you wrote a regression test that fails, I could fix it.  I've
: 
: fixed every related problem I know about.

A test is fairly complex because it should involve multiple files; the
problem itself is simple though:
In the documentation of Module::Build you say one should use

   use lib qw(/nonstandard/library/path);

in Build.PL to include custom modules. Now in Compat.pm you use system()
to run Build.PL, which means that this "use lib" statement is only
executed in a _forked_ process. Later the process executing Makefile.PL
dies because it can't find the custom module.

The patch is simple and I first posted it to the mailing list at the
12th of april. The idea is to replace the system() in
M:B:Compat::run_build_pl() with a do(), this way everything takes place
M:in the same process, thus loading the correct nonstandard library
M:path.

This patch fixes the problems for me:
Module/Build/Compat.pm
173c173,175
<   system($^X, $in{script},  <at> args) == 0 or die "Couldn't run
$in{script}: $!";
---
>   local  <at> ARGV =  <at> args;
>   do $in{script};
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrew Savige | 17 May 2004 01:02
Picon

Re: [Module::Build] how to deal with special files in lib/

Carsten Milling wrote:
> I have some files other than .pm or .pod in my lib/ tree (e.g. some
> xsl stylesheets used by the module internally). I understand that by
> default these don't get copied to blib/ and installed subsequently.
> How am I supposed to customize my Build.PL (or a Module::Build
> subclass for that matter) to get these files installed
> properly. Shouldn't there be an easy way to achieve this? Maybe I'm
> just blind, but I didn't find any hint in the Module::Build manpage
> nor the CookBook.

Carsten, thanks for asking, because I have the same problem with
Acme::EyeDrops; this module has a bunch of .eye files, which are
data for EyeDrops.pm, so I want them to be copied whereever
EyeDrops.pm is copied (EyeDrops.pm uses the Perl __FILE__
variable to find them relative to itself).

Here is what I am currently using in Build.PL:

my $class = Module::Build->subclass(
   class => 'My::Builder',
   code => q{
      sub find_pm_files {
         my $self = shift;
         return { ( %{$self->_find_file_by_type('pm',  'lib')},
                    %{$self->_find_file_by_type('eye', 'lib')} ) };
      }
   }
);
my $m = $class->new(
   module_name =>     'Acme::EyeDrops',
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Williams | 17 May 2004 06:19
Favicon

Re: [Module::Build] how to deal with special files in lib/


On May 16, 2004, at 6:02 PM, Andrew Savige wrote:

> Carsten Milling wrote:
>> I have some files other than .pm or .pod in my lib/ tree (e.g. some
>> xsl stylesheets used by the module internally). I understand that by
>> default these don't get copied to blib/ and installed subsequently.
>> How am I supposed to customize my Build.PL (or a Module::Build
>> subclass for that matter) to get these files installed
>> properly. Shouldn't there be an easy way to achieve this? Maybe I'm
>> just blind, but I didn't find any hint in the Module::Build manpage
>> nor the CookBook.
>
> Carsten, thanks for asking, because I have the same problem with
> Acme::EyeDrops; this module has a bunch of .eye files, which are
> data for EyeDrops.pm, so I want them to be copied whereever
> EyeDrops.pm is copied (EyeDrops.pm uses the Perl __FILE__
> variable to find them relative to itself).

Aside: it might be better to search for them in  <at> INC, so that the user 
could put them in a private library directory if he/she wanted.

> Here is what I am currently using in Build.PL:
>
> my $class = Module::Build->subclass(
>    class => 'My::Builder',
>    code => q{
>       sub find_pm_files {
>          my $self = shift;
>          return { ( %{$self->_find_file_by_type('pm',  'lib')},
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Williams | 18 May 2004 06:07
Favicon

Re: [Module::Build] Compat BUG


On May 15, 2004, at 5:13 AM, Jaap Karssenberg wrote:
>
> The patch is simple and I first posted it to the mailing list at the
> 12th of april. The idea is to replace the system() in
> M:B:Compat::run_build_pl() with a do(), this way everything takes place
> M:in the same process, thus loading the correct nonstandard library
> M:path.
>
> This patch fixes the problems for me:
> Module/Build/Compat.pm
> 173c173,175
> <   system($^X, $in{script},  <at> args) == 0 or die "Couldn't run
> $in{script}: $!";
> ---
>>   local  <at> ARGV =  <at> args;
>>   do $in{script};
>>   die if $ <at> ;
>
> The only risk is that one might end a Build.PL with 'exit', you could
> advise against this in the documentation about subclassing.

I like the spirit of the patch, but when I apply it I get a bunch of 
failures in the regression tests.  I'm not sure why yet.

  -Ken

-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
(Continue reading)

Permalink | Reply | 2 comments |
headers
Randy W. Sims | 18 May 2004 06:55

Re: [Module::Build] Compat BUG

Ken Williams wrote:
> 
> On May 15, 2004, at 5:13 AM, Jaap Karssenberg wrote:
> 
>>
>> The patch is simple and I first posted it to the mailing list at the
>> 12th of april. The idea is to replace the system() in
>> M:B:Compat::run_build_pl() with a do(), this way everything takes place
>> M:in the same process, thus loading the correct nonstandard library
>> M:path.
>>
>> This patch fixes the problems for me:
>> Module/Build/Compat.pm
>> 173c173,175
>> <   system($^X, $in{script},  <at> args) == 0 or die "Couldn't run
>> $in{script}: $!";
>> ---
>>
>>>   local  <at> ARGV =  <at> args;
>>>   do $in{script};
>>>   die if $ <at> ;
>>
>>
>> The only risk is that one might end a Build.PL with 'exit', you could
>> advise against this in the documentation about subclassing.
> 
> 
> I like the spirit of the patch, but when I apply it I get a bunch of 
> failures in the regression tests.  I'm not sure why yet.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane