Discussion:
[Pdl-porters] Simplified Makefile.PL (better EUMM integration)
kmx
2015-01-05 23:20:34 UTC
Permalink
Hi,

I have a suggestion for improved ExtUtils::MakeMaker support in PDL.

It basically means patching PDL::Core::Dev like this (just a proof of
concept - working, but not much tested):
https://gist.github.com/kmx/5d740bc6f959c014516f

The patch:

1/ Introduces a new function pdlpp_eumm(%args) which is kind of a
replacement for pdlpp_stdargs - the added value is that pdlpp_eumm does
some kind of automatic merging (see the patch).

2/ Uses a trick that we do not need to write "sub MY::postamble" - stolen
from Inline::Module.

See sample Makefile.PL below.

The new-style Makefile.PL looks definitely simpler and easier to read/write
but I am not sure if the gain is worth changing the established traditional
way of writing PDL's Makefiles.

--
kmx



################ Makefile.PL - current-style
use ExtUtils::MakeMaker;
use PDL::Core::Dev;

my $libs = `ta-lib-config --libs`;
my $cflags = `ta-lib-config --cflags`;
unless ($libs && $cflags) {
warn "ta-lib not found";
exit 0;
}

my $package = [qw/TA.pd TA PDL::Finance::TA/];
my %eumm_args = pdlpp_stdargs($package);
$eumm_args{INC} .= " $cflags";
$eumm_args{LIBS} ->[0] .= " $libs";

WriteMakefile(
%eumm_args,
VERSION_FROM => 'TA.pd',
AUTHOR => 'KMX <***@cpan.org>',
ABSTRACT => 'PDL interface to ta-lib library',
LICENSE => 'perl',
PREREQ_PM => {
'PDL' => 0,
},
BUILD_REQUIRES => {
'PDL' => 0,
'Test::More' => 0,
'Test::Number::Delta' => 0,
},
CONFIGURE_REQUIRES => {
'PDL' => 0,
},
META_MERGE => {
resources => {
repository => 'https://github.com/kmx/pdl-finance-ta',
},
},
);

sub MY::postamble {
pdlpp_postamble($package);
}
################ end of current-style




################ Makefile.PL - new-style
use ExtUtils::MakeMaker;
use PDL::Core::Dev;

my $libs = `ta-lib-config --libs`;
my $cflags = `ta-lib-config --cflags`;
unless ($libs && $cflags) {
warn "ta-lib not found";
exit 0;
}

WriteMakefile(pdlpp_eumm(
PDL_PD => { TA.pd => PDL::Finance::TA },
VERSION_FROM => 'TA.pd',
AUTHOR => 'KMX <***@cpan.org>',
ABSTRACT => 'PDL interface to ta-lib library',
LICENSE => 'perl',
INC => $cflags,
LIBS => $libs,
BUILD_REQUIRES => {
'Test::More' => 0,
'Test::Number::Delta' => 0,
},
META_MERGE => {
resources => {
repository => 'https://github.com/kmx/pdl-finance-ta',
},
},
));
################ end of new-style
Ed .
2015-01-06 02:29:38 UTC
Permalink
This is a dramatically overcomplicated and sub-correct solution to the perceived problem.

From: kmx
Sent: Monday, January 05, 2015 11:20 PM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)

Hi,

I have a suggestion for improved ExtUtils::MakeMaker support in PDL.

It basically means patching PDL::Core::Dev like this (just a proof of concept - working, but not much tested):
https://gist.github.com/kmx/5d740bc6f959c014516f

The patch:

1/ Introduces a new function pdlpp_eumm(%args) which is kind of a replacement for pdlpp_stdargs - the added value is that pdlpp_eumm does some kind of automatic merging (see the patch).

2/ Uses a trick that we do not need to write "sub MY::postamble" - stolen from Inline::Module.

See sample Makefile.PL below.

The new-style Makefile.PL looks definitely simpler and easier to read/write but I am not sure if the gain is worth changing the established traditional way of writing PDL's Makefiles.

--
kmx



################ Makefile.PL - current-style
use ExtUtils::MakeMaker;
use PDL::Core::Dev;

my $libs = `ta-lib-config --libs`;
my $cflags = `ta-lib-config --cflags`;
unless ($libs && $cflags) {
warn "ta-lib not found";
exit 0;
}

my $package = [qw/TA.pd TA PDL::Finance::TA/];
my %eumm_args = pdlpp_stdargs($package);
$eumm_args{INC} .= " $cflags";
$eumm_args{LIBS} ->[0] .= " $libs";

WriteMakefile(
%eumm_args,
VERSION_FROM => 'TA.pd',
AUTHOR => 'KMX mailto:***@cpan.org',
ABSTRACT => 'PDL interface to ta-lib library',
LICENSE => 'perl',
PREREQ_PM => {
'PDL' => 0,
},
BUILD_REQUIRES => {
'PDL' => 0,
'Test::More' => 0,
'Test::Number::Delta' => 0,
},
CONFIGURE_REQUIRES => {
'PDL' => 0,
},
META_MERGE => {
resources => {
repository => 'https://github.com/kmx/pdl-finance-ta',
},
},
);

sub MY::postamble {
pdlpp_postamble($package);
}
################ end of current-style




################ Makefile.PL - new-style
use ExtUtils::MakeMaker;
use PDL::Core::Dev;

my $libs = `ta-lib-config --libs`;
my $cflags = `ta-lib-config --cflags`;
unless ($libs && $cflags) {
warn "ta-lib not found";
exit 0;
}

WriteMakefile(pdlpp_eumm(
PDL_PD => { TA.pd => PDL::Finance::TA },
VERSION_FROM => 'TA.pd',
AUTHOR => 'KMX mailto:***@cpan.org',
ABSTRACT => 'PDL interface to ta-lib library',
LICENSE => 'perl',
INC => $cflags,
LIBS => $libs,
BUILD_REQUIRES => {
'Test::More' => 0,
'Test::Number::Delta' => 0,
},
META_MERGE => {
resources => {
repository => 'https://github.com/kmx/pdl-finance-ta',
},
},
));
################ end of new-style




--------------------------------------------------------------------------------
Chris Marshall
2015-01-06 05:20:14 UTC
Permalink
Now that we have the hyperbole out of the way, how about some more
constructive suggestions... :-)
Post by Ed .
This is a dramatically overcomplicated and sub-correct solution to the perceived problem.
*Sent:* Monday, January 05, 2015 11:20 PM
*Subject:* [Pdl-porters] Simplified Makefile.PL (better EUMM integration)
Hi,
I have a suggestion for improved ExtUtils::MakeMaker support in PDL.
It basically means patching PDL::Core::Dev like this (just a proof of
https://gist.github.com/kmx/5d740bc6f959c014516f
1/ Introduces a new function pdlpp_eumm(%args) which is kind of a
replacement for pdlpp_stdargs - the added value is that pdlpp_eumm does
some kind of automatic merging (see the patch).
2/ Uses a trick that we do not need to write "sub MY::postamble" - stolen
from Inline::Module.
See sample Makefile.PL below.
The new-style Makefile.PL looks definitely simpler and easier to
read/write but I am not sure if the gain is worth changing the established
traditional way of writing PDL's Makefiles.
--
kmx
################ Makefile.PL - current-style
use ExtUtils::MakeMaker;
use PDL::Core::Dev;
my $libs = `ta-lib-config --libs`;
my $cflags = `ta-lib-config --cflags`;
unless ($libs && $cflags) {
warn "ta-lib not found";
exit 0;
}
my $package = [qw/TA.pd TA PDL::Finance::TA/];
my %eumm_args = pdlpp_stdargs($package);
$eumm_args{INC} .= " $cflags";
$eumm_args{LIBS} ->[0] .= " $libs";
WriteMakefile(
%eumm_args,
VERSION_FROM => 'TA.pd',
ABSTRACT => 'PDL interface to ta-lib library',
LICENSE => 'perl',
PREREQ_PM => {
'PDL' => 0,
},
BUILD_REQUIRES => {
'PDL' => 0,
'Test::More' => 0,
'Test::Number::Delta' => 0,
},
CONFIGURE_REQUIRES => {
'PDL' => 0,
},
META_MERGE => {
resources => {
repository => 'https://github.com/kmx/pdl-finance-ta',
},
},
);
sub MY::postamble {
pdlpp_postamble($package);
}
################ end of current-style
################ Makefile.PL - new-style
use ExtUtils::MakeMaker;
use PDL::Core::Dev;
my $libs = `ta-lib-config --libs`;
my $cflags = `ta-lib-config --cflags`;
unless ($libs && $cflags) {
warn "ta-lib not found";
exit 0;
}
WriteMakefile(pdlpp_eumm(
PDL_PD => { TA.pd => PDL::Finance::TA },
VERSION_FROM => 'TA.pd',
ABSTRACT => 'PDL interface to ta-lib library',
LICENSE => 'perl',
INC => $cflags,
LIBS => $libs,
BUILD_REQUIRES => {
'Test::More' => 0,
'Test::Number::Delta' => 0,
},
META_MERGE => {
resources => {
repository => 'https://github.com/kmx/pdl-finance-ta',
},
},
));
################ end of new-style
------------------------------
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
s***@optusnet.com.au
2015-01-06 12:14:07 UTC
Permalink
From: kmx
Sent: Tuesday, January 06, 2015 10:20 AM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)
Post by kmx
I have a suggestion for improved ExtUtils::MakeMaker support in PDL.
kmx,

Have you built PDL-2.007_06 on Windows using EU-MM-7 by any chance ?
No problems with EU-MM-6 but, for me (EU-MM-7.0505), 'dmake test' terminates
very noisily - see attached test_termination.txt.
There's no actual failure - it's merely dmake noise.

Initially I thought it was going to be caused by the postamble, but both the
quiet (version 6) Makefile and the noisy (version 7) Makefile contain
identical 'postamble' sections so I'm now thinking it must be something
else.
See the attached diff.txt for the differences between the 2 Makefiles that
were generated for Lib/GSL/SF/zeta (which is one of the affected modules).

Anyway - just wanted to mention this in case it ties in with anything you're
looking at.
If it's a separate issue then I'll try to sort it out - but I don't want to
start messing with it if that's going to interfere with your plans.

Cheers,
Rob
kmx
2015-01-06 13:26:12 UTC
Permalink
Rob,

For me PDL-2.007_06 builds fine with ExtUtils::MakeMaker-7.04

Will try EU-MM-7.0505 later today.

--
kmx
Post by Ed .
From: kmx
Sent: Tuesday, January 06, 2015 10:20 AM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)
Post by kmx
I have a suggestion for improved ExtUtils::MakeMaker support in PDL.
kmx,
Have you built PDL-2.007_06 on Windows using EU-MM-7 by any chance ?
No problems with EU-MM-6 but, for me (EU-MM-7.0505), 'dmake test'
terminates very noisily - see attached test_termination.txt.
There's no actual failure - it's merely dmake noise.
Initially I thought it was going to be caused by the postamble, but both
the quiet (version 6) Makefile and the noisy (version 7) Makefile contain
identical 'postamble' sections so I'm now thinking it must be something
else.
See the attached diff.txt for the differences between the 2 Makefiles
that were generated for Lib/GSL/SF/zeta (which is one of the affected
modules).
Anyway - just wanted to mention this in case it ties in with anything
you're looking at.
If it's a separate issue then I'll try to sort it out - but I don't want
to start messing with it if that's going to interfere with your plans.
Cheers,
Rob
kmx
2015-01-06 17:20:30 UTC
Permalink
My PDL-2.007_06 + ExtUtils-MakeMaker-7.05_05 fails exactly as yours.

Unfortunately I am short of time right now to investigate more.

--
kmx
Post by kmx
Rob,
For me PDL-2.007_06 builds fine with ExtUtils::MakeMaker-7.04
Will try EU-MM-7.0505 later today.
--
kmx
Post by Ed .
From: kmx
Sent: Tuesday, January 06, 2015 10:20 AM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)
Post by kmx
I have a suggestion for improved ExtUtils::MakeMaker support in PDL.
kmx,
Have you built PDL-2.007_06 on Windows using EU-MM-7 by any chance ?
No problems with EU-MM-6 but, for me (EU-MM-7.0505), 'dmake test'
terminates very noisily - see attached test_termination.txt.
There's no actual failure - it's merely dmake noise.
Initially I thought it was going to be caused by the postamble, but both
the quiet (version 6) Makefile and the noisy (version 7) Makefile
contain identical 'postamble' sections so I'm now thinking it must be
something else.
See the attached diff.txt for the differences between the 2 Makefiles
that were generated for Lib/GSL/SF/zeta (which is one of the affected
modules).
Anyway - just wanted to mention this in case it ties in with anything
you're looking at.
If it's a separate issue then I'll try to sort it out - but I don't want
to start messing with it if that's going to interfere with your plans.
Cheers,
Rob
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
kmx
2015-01-07 14:26:57 UTC
Permalink
Hi Rob,

(moving the topic to a different thread)

Further testing revealed that EUMM-7.05_05 adds this new section into
generated Makefiles (with EUMM-7.04 this section is empty):

# --- MakeMaker xs_o section:
.xs$(OBJ_EXT) :
$(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.xsc
$(MV) $*.xsc $*.c
$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE)
$*.c -o $*$(OBJ_EXT)

Then the dmake warning is true, there are 2 ambiguous build paths from *.xs
to *.o

1/ .xs.c: rule + .c$(OBJ_EXT): rule

2/ direct .xs$(OBJ_EXT): rule

So it is clearly a bug in EUMM introduced in 7.05_05

I suspect this commit:
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/8e4059c6
Ed, isn't it yours?

--
kmx
Post by kmx
My PDL-2.007_06 + ExtUtils-MakeMaker-7.05_05 fails exactly as yours.
Unfortunately I am short of time right now to investigate more.
--
kmx
Post by kmx
Rob,
For me PDL-2.007_06 builds fine with ExtUtils::MakeMaker-7.04
Will try EU-MM-7.0505 later today.
--
kmx
Post by Ed .
From: kmx
Sent: Tuesday, January 06, 2015 10:20 AM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)
Post by kmx
I have a suggestion for improved ExtUtils::MakeMaker support in PDL.
kmx,
Have you built PDL-2.007_06 on Windows using EU-MM-7 by any chance ?
No problems with EU-MM-6 but, for me (EU-MM-7.0505), 'dmake test'
terminates very noisily - see attached test_termination.txt.
There's no actual failure - it's merely dmake noise.
Initially I thought it was going to be caused by the postamble, but
both the quiet (version 6) Makefile and the noisy (version 7) Makefile
contain identical 'postamble' sections so I'm now thinking it must be
something else.
See the attached diff.txt for the differences between the 2 Makefiles
that were generated for Lib/GSL/SF/zeta (which is one of the affected
modules).
Anyway - just wanted to mention this in case it ties in with anything
you're looking at.
If it's a separate issue then I'll try to sort it out - but I don't
want to start messing with it if that's going to interfere with your
plans.
Cheers,
Rob
Ed .
2015-01-07 14:37:18 UTC
Permalink
It is. If you wish to continue down the path of adding more and more code, you could make a MY::xs_o that overrides and doesn’t have that. That may be temporarily necessary here, although EUMM 7.05_05 is a dev release.

When EUMM 7.06 comes out, it ought to have XSMULTI available, which will enable a vastly simpler build system.

From: kmx
Sent: Wednesday, January 07, 2015 2:26 PM
To: pdl-***@jach.hawaii.edu
Subject: [Pdl-porters] dmake + EUMM-7.05_05 trouble

Hi Rob,

(moving the topic to a different thread)

Further testing revealed that EUMM-7.05_05 adds this new section into generated Makefiles (with EUMM-7.04 this section is empty):

# --- MakeMaker xs_o section:
.xs$(OBJ_EXT) :
$(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.xsc
$(MV) $*.xsc $*.c
$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE) $*.c -o $*$(OBJ_EXT)

Then the dmake warning is true, there are 2 ambiguous build paths from *.xs to *.o

1/ .xs.c: rule + .c$(OBJ_EXT): rule

2/ direct .xs$(OBJ_EXT): rule

So it is clearly a bug in EUMM introduced in 7.05_05

I suspect this commit:
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/8e4059c6
Ed, isn't it yours?

--
kmx


On 6.1.2015 18:20, kmx wrote:

My PDL-2.007_06 + ExtUtils-MakeMaker-7.05_05 fails exactly as yours.

Unfortunately I am short of time right now to investigate more.

--
kmx


On 6.1.2015 14:26, kmx wrote:

Rob,

For me PDL-2.007_06 builds fine with ExtUtils::MakeMaker-7.04

Will try EU-MM-7.0505 later today.

--
kmx

On 6.1.2015 13:14, ***@optusnet.com.au wrote:

From: kmx
Sent: Tuesday, January 06, 2015 10:20 AM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)


I have a suggestion for improved ExtUtils::MakeMaker support in PDL.


kmx,

Have you built PDL-2.007_06 on Windows using EU-MM-7 by any chance ?
No problems with EU-MM-6 but, for me (EU-MM-7.0505), 'dmake test' terminates very noisily - see attached test_termination.txt.
There's no actual failure - it's merely dmake noise.

Initially I thought it was going to be caused by the postamble, but both the quiet (version 6) Makefile and the noisy (version 7) Makefile contain identical 'postamble' sections so I'm now thinking it must be something else.
See the attached diff.txt for the differences between the 2 Makefiles that were generated for Lib/GSL/SF/zeta (which is one of the affected modules).

Anyway - just wanted to mention this in case it ties in with anything you're looking at.
If it's a separate issue then I'll try to sort it out - but I don't want to start messing with it if that's going to interfere with your plans.

Cheers,
Rob







--------------------------------------------------------------------------------
Chris Marshall
2015-01-07 16:07:26 UTC
Permalink
Since this is for a developers release, I suggest added this information to
the Known_problems for PDL-2.008.
Post by Ed .
It is. If you wish to continue down the path of adding more and more
code, you could make a MY::xs_o that overrides and doesn’t have that. That
may be temporarily necessary here, although EUMM 7.05_05 is a dev release.
When EUMM 7.06 comes out, it ought to have XSMULTI available, which will
enable a vastly simpler build system.
*Sent:* Wednesday, January 07, 2015 2:26 PM
*Subject:* [Pdl-porters] dmake + EUMM-7.05_05 trouble
Hi Rob,
(moving the topic to a different thread)
Further testing revealed that EUMM-7.05_05 adds this new section into
$(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.xsc
$(MV) $*.xsc $*.c
$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE) $*.c -o $*$(OBJ_EXT)
Then the dmake warning is true, there are 2 ambiguous build paths from *.xs to *.o
1/ .xs.c: rule + .c$(OBJ_EXT): rule
2/ direct .xs$(OBJ_EXT): rule
So it is clearly a bug in EUMM introduced in 7.05_05
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/8e4059c6
Ed, isn't it yours?
--
kmx
My PDL-2.007_06 + ExtUtils-MakeMaker-7.05_05 fails exactly as yours.
Unfortunately I am short of time right now to investigate more.
--
kmx
Rob,
For me PDL-2.007_06 builds fine with ExtUtils::MakeMaker-7.04
Will try EU-MM-7.0505 later today.
--
kmx
From: kmx
Sent: Tuesday, January 06, 2015 10:20 AM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)
I have a suggestion for improved ExtUtils::MakeMaker support in PDL.
kmx,
Have you built PDL-2.007_06 on Windows using EU-MM-7 by any chance ?
No problems with EU-MM-6 but, for me (EU-MM-7.0505), 'dmake test'
terminates very noisily - see attached test_termination.txt.
There's no actual failure - it's merely dmake noise.
Initially I thought it was going to be caused by the postamble, but both
the quiet (version 6) Makefile and the noisy (version 7) Makefile contain
identical 'postamble' sections so I'm now thinking it must be something
else.
See the attached diff.txt for the differences between the 2 Makefiles that
were generated for Lib/GSL/SF/zeta (which is one of the affected modules).
Anyway - just wanted to mention this in case it ties in with anything you're looking at.
If it's a separate issue then I'll try to sort it out - but I don't want
to start messing with it if that's going to interfere with your plans.
Cheers,
Rob
------------------------------
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
kmx
2015-01-07 18:27:33 UTC
Permalink
Ed, should I create an EUMM issue for this?

--
kmx
Post by Chris Marshall
Since this is for a developers release, I suggest added this information
to the Known_problems for PDL-2.008.
It is. If you wish to continue down the path of adding more and more
code, you could make a MY::xs_o that overrides and doesn’t have that.
That may be temporarily necessary here, although EUMM 7.05_05 is a
dev release.
When EUMM 7.06 comes out, it ought to have XSMULTI available, which
will enable a vastly simpler build system.
*Sent:* Wednesday, January 07, 2015 2:26 PM
*Subject:* [Pdl-porters] dmake + EUMM-7.05_05 trouble
Hi Rob,
(moving the topic to a different thread)
Further testing revealed that EUMM-7.05_05 adds this new section into
$(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.xsc
$(MV) $*.xsc $*.c
$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE)
$(DEFINE) $*.c -o $*$(OBJ_EXT)
Then the dmake warning is true, there are 2 ambiguous build paths from *.xs to *.o
1/ .xs.c: rule + .c$(OBJ_EXT): rule
2/ direct .xs$(OBJ_EXT): rule
So it is clearly a bug in EUMM introduced in 7.05_05
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/8e4059c6
Ed, isn't it yours?
--
kmx
Post by kmx
My PDL-2.007_06 + ExtUtils-MakeMaker-7.05_05 fails exactly as yours.
Unfortunately I am short of time right now to investigate more.
--
kmx
Post by kmx
Rob,
For me PDL-2.007_06 builds fine with ExtUtils::MakeMaker-7.04
Will try EU-MM-7.0505 later today.
--
kmx
Post by Ed .
From: kmx
Sent: Tuesday, January 06, 2015 10:20 AM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)
Post by kmx
I have a suggestion for improved ExtUtils::MakeMaker support in PDL.
kmx,
Have you built PDL-2.007_06 on Windows using EU-MM-7 by any chance ?
No problems with EU-MM-6 but, for me (EU-MM-7.0505), 'dmake test'
terminates very noisily - see attached test_termination.txt.
There's no actual failure - it's merely dmake noise.
Initially I thought it was going to be caused by the postamble,
but both the quiet (version 6) Makefile and the noisy (version 7)
Makefile contain identical 'postamble' sections so I'm now
thinking it must be something else.
See the attached diff.txt for the differences between the 2
Makefiles that were generated for Lib/GSL/SF/zeta (which is one of
the affected modules).
Anyway - just wanted to mention this in case it ties in with
anything you're looking at.
If it's a separate issue then I'll try to sort it out - but I
don't want to start messing with it if that's going to interfere
with your plans.
Cheers,
Rob
---------------------------------------------------------------------------
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
_______________________________________________
PDL-porters mailing list
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters
Ed .
2015-01-07 18:33:41 UTC
Permalink
Yes, please do. Please reduce the relevant Makefile.PL down to the minimum so the problem can be reproduced, and it can be added to a test to avoid future regressions.

From: kmx
Sent: Wednesday, January 07, 2015 6:27 PM
To: pdl-porters
Subject: Re: [Pdl-porters] dmake + EUMM-7.05_05 trouble

Ed, should I create an EUMM issue for this?

--
kmx


On 7.1.2015 17:07, Chris Marshall wrote:

Since this is for a developers release, I suggest added this information to the Known_problems for PDL-2.008.


On Wed, Jan 7, 2015 at 9:37 AM, Ed . <***@hotmail.com> wrote:

It is. If you wish to continue down the path of adding more and more code, you could make a MY::xs_o that overrides and doesn’t have that. That may be temporarily necessary here, although EUMM 7.05_05 is a dev release.

When EUMM 7.06 comes out, it ought to have XSMULTI available, which will enable a vastly simpler build system.

From: kmx
Sent: Wednesday, January 07, 2015 2:26 PM
To: pdl-***@jach.hawaii.edu
Subject: [Pdl-porters] dmake + EUMM-7.05_05 trouble

Hi Rob,

(moving the topic to a different thread)

Further testing revealed that EUMM-7.05_05 adds this new section into generated Makefiles (with EUMM-7.04 this section is empty):

# --- MakeMaker xs_o section:
.xs$(OBJ_EXT) :
$(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $*.xs > $*.xsc
$(MV) $*.xsc $*.c
$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE) $*.c -o $*$(OBJ_EXT)

Then the dmake warning is true, there are 2 ambiguous build paths from *.xs to *.o

1/ .xs.c: rule + .c$(OBJ_EXT): rule

2/ direct .xs$(OBJ_EXT): rule

So it is clearly a bug in EUMM introduced in 7.05_05

I suspect this commit:
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/8e4059c6
Ed, isn't it yours?

--
kmx


On 6.1.2015 18:20, kmx wrote:

My PDL-2.007_06 + ExtUtils-MakeMaker-7.05_05 fails exactly as yours.

Unfortunately I am short of time right now to investigate more.

--
kmx


On 6.1.2015 14:26, kmx wrote:

Rob,

For me PDL-2.007_06 builds fine with ExtUtils::MakeMaker-7.04

Will try EU-MM-7.0505 later today.

--
kmx

On 6.1.2015 13:14, ***@optusnet.com.au wrote:

From: kmx
Sent: Tuesday, January 06, 2015 10:20 AM
To: pdl-porters
Subject: [Pdl-porters] Simplified Makefile.PL (better EUMM integration)


I have a suggestion for improved ExtUtils::MakeMaker support in PDL.


kmx,

Have you built PDL-2.007_06 on Windows using EU-MM-7 by any chance ?
No problems with EU-MM-6 but, for me (EU-MM-7.0505), 'dmake test' terminates very noisily - see attached test_termination.txt.
There's no actual failure - it's merely dmake noise.

Initially I thought it was going to be caused by the postamble, but both the quiet (version 6) Makefile and the noisy (version 7) Makefile contain identical 'postamble' sections so I'm now thinking it must be something else.
See the attached diff.txt for the differences between the 2 Makefiles that were generated for Lib/GSL/SF/zeta (which is one of the affected modules).

Anyway - just wanted to mention this in case it ties in with anything you're looking at.
If it's a separate issue then I'll try to sort it out - but I don't want to start messing with it if that's going to interfere with your plans.

Cheers,
Rob






----------------------------------------------------------------------------
_______________________________________________
PDL-porters mailing list
PDL-***@jach.hawaii.edu
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters


_______________________________________________
PDL-porters mailing list
PDL-***@jach.hawaii.edu
http://mailman.jach.hawaii.edu/mailman/listinfo/pdl-porters







--------------------------------------------------------------------------------
s***@optusnet.com.au
2015-01-07 23:51:50 UTC
Permalink
From: kmx
Sent: Thursday, January 08, 2015 1:26 AM
To: pdl-***@jach.hawaii.edu
Subject: [Pdl-porters] dmake + EUMM-7.05_05 trouble
Post by kmx
Further testing revealed that EUMM-7.05_05 adds this new section into
Thanks.

I find the same warnings with other perl extensions when they're built and
tested manually with:

perl Makefile.PL
dmake
dmake test

In these cases the same warnings appear in relation to top level files as
well as subdirs (if there are any subdirs).

If, instead, I just build with:

perl Makefile.PL
dmake test

then the warnings only appear in relation to subdirs - unless, of course, I
subsequently re-run 'dmake test', in which case the warnings will appear for
all directories.

Cheers,
Rob
Ed .
2015-01-08 02:06:14 UTC
Permalink
I've just pushed a change to EUMM that should suppress these warnings.
Please try git latest EUMM on your code and let me know.

Ed

-----Original Message-----
From: ***@optusnet.com.au
Sent: Wednesday, January 07, 2015 11:51 PM
To: kmx ; pdl-***@jach.hawaii.edu
Subject: Re: [Pdl-porters] dmake + EUMM-7.05_05 trouble


From: kmx
Sent: Thursday, January 08, 2015 1:26 AM
To: pdl-***@jach.hawaii.edu
Subject: [Pdl-porters] dmake + EUMM-7.05_05 trouble
Post by kmx
Further testing revealed that EUMM-7.05_05 adds this new section into
Thanks.

I find the same warnings with other perl extensions when they're built and
tested manually with:

perl Makefile.PL
dmake
dmake test

In these cases the same warnings appear in relation to top level files as
well as subdirs (if there are any subdirs).

If, instead, I just build with:

perl Makefile.PL
dmake test

then the warnings only appear in relation to subdirs - unless, of course, I
subsequently re-run 'dmake test', in which case the warnings will appear for
all directories.

Cheers,
Rob
s***@optusnet.com.au
2015-01-08 03:30:21 UTC
Permalink
-----Original Message-----
From: Ed .
Sent: Thursday, January 08, 2015 1:06 PM
To: ***@optusnet.com.au ; kmx
Cc: pdl-porters
Subject: Re: [Pdl-porters] dmake + EUMM-7.05_05 trouble
Post by Ed .
I've just pushed a change to EUMM that should suppress these warnings.
Please try git latest EUMM on your code and let me know.
That takes care of the dmake noise for me.

One (very) minor quibble is that, during 'dmake test', I'm getting a
tripling up of the 'No tests defined for Module::Whatever::Foo extension'
warnings.
For example, with Math-MPFR-3.23:

#####################################
C:\sisyphusion\Math-MPFR-3.23>dmake test
'No tests defined for Math::MPFR::Prec extension.'
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty --
MPFR.bs blib\arch\auto\Math\MPFR\MPFR.bs 644
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty --
Prec.bs ..\blib\arch\auto\Math\MPFR\Prec\Prec.bs 644
'No tests defined for Math::MPFR::Prec extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty --
V.bs ..\blib\arch\auto\Math\MPFR\V\V.bs 644
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e"
"undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')"
t/*.
t
t/_1aaa_v.t ...............
[snip running of test suite]
t/uselongdouble.t ......... ok
All tests successful.
Files=47, Tests=729, 13 wallclock secs ( 0.17 usr + 0.03 sys = 0.20 CPU)
Result: PASS
'No tests defined for Math::MPFR::Prec extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty --
Prec.bs ..\blib\arch\auto\Math\MPFR\Prec\Prec.bs 644
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty --
V.bs ..\blib\arch\auto\Math\MPFR\V\V.bs 644

C:\sisyphusion\Math-MPFR-3.23>
#####################################

That might bother purists - I'm not a purist, so I don't know.
I guess I could always add a t/test.t for the Math::MPFR::Prec and
Math::MPFR::V extensions - though such a solution wouldn't scale so well wrt
PDL ;-)

Cheers,
Rob
kmx
2015-01-08 08:26:17 UTC
Permalink
Ed, your dmake-related patch did the trick (you were faster than me
submitting the issue :)

Ad Rob's comment:

Newly introduced lines with "cp_nonempty" can be IMO easily silenced by
changing:
$(CP_NONEMPTY) $(BASEEXT).bs $(INST_ARCHAUTODIR)\$(BASEEXT).bs $(PERM_RW)
to:
$(NOECHO) $(CP_NONEMPTY) $(BASEEXT).bs $(INST_ARCHAUTODIR)\$(BASEEXT).bs
$(PERM_RW)

As for duplicated 'No tests defined for ...' I have no idea but agree that
it will make PDL test suite very noisy. What I have found out is that it is
not specific to dmake, same trouble on cygwin.

--
kmx
-----Original Message----- From: Ed .
Sent: Thursday, January 08, 2015 1:06 PM
Cc: pdl-porters
Subject: Re: [Pdl-porters] dmake + EUMM-7.05_05 trouble
Post by Ed .
I've just pushed a change to EUMM that should suppress these warnings.
Please try git latest EUMM on your code and let me know.
That takes care of the dmake noise for me.
One (very) minor quibble is that, during 'dmake test', I'm getting a
tripling up of the 'No tests defined for Module::Whatever::Foo extension'
warnings.
#####################################
C:\sisyphusion\Math-MPFR-3.23>dmake test
'No tests defined for Math::MPFR::Prec extension.'
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty
-- MPFR.bs blib\arch\auto\Math\MPFR\MPFR.bs 644
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty
-- Prec.bs ..\blib\arch\auto\Math\MPFR\Prec\Prec.bs 644
'No tests defined for Math::MPFR::Prec extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty
-- V.bs ..\blib\arch\auto\Math\MPFR\V\V.bs 644
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" "-MExtUtils::Command::MM"
"-MTest::Harness" "-e"
"undef *Test::Harness::Switches; test_harness(0, 'blib\lib',
'blib\arch')" t/*.
t
t/_1aaa_v.t ...............
[snip running of test suite]
t/uselongdouble.t ......... ok
All tests successful.
Files=47, Tests=729, 13 wallclock secs ( 0.17 usr + 0.03 sys = 0.20 CPU)
Result: PASS
'No tests defined for Math::MPFR::Prec extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty
-- Prec.bs ..\blib\arch\auto\Math\MPFR\Prec\Prec.bs 644
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty
-- V.bs ..\blib\arch\auto\Math\MPFR\V\V.bs 644
C:\sisyphusion\Math-MPFR-3.23>
#####################################
That might bother purists - I'm not a purist, so I don't know.
I guess I could always add a t/test.t for the Math::MPFR::Prec and
Math::MPFR::V extensions - though such a solution wouldn't scale so well
wrt PDL ;-)
Cheers,
Rob
Ed .
2015-01-09 03:29:26 UTC
Permalink
The extra “No tests defined” messages were due to a wrongly-placed recipe which was exposed by the recent split of the pure_all target into dynamic and pure_nolink, each of which (along with tests) has its own subdirs target.

The “No tests” message has been attached to the correct target now in EUMM git master. You will still see more “entering/leaving” messages during tests, since tests depend on dynamic, which depends on pure_nolink. The way to avoid these is to use XSMULTI, as I intend to demonstrate quite soon.

Ed

From: kmx
Sent: Thursday, January 08, 2015 8:26 AM
To: ***@optusnet.com.au ; Ed .
Cc: pdl-porters
Subject: Re: [Pdl-porters] dmake + EUMM-7.05_05 trouble

Ed, your dmake-related patch did the trick (you were faster than me submitting the issue :)

Ad Rob's comment:

Newly introduced lines with "cp_nonempty" can be IMO easily silenced by changing:
$(CP_NONEMPTY) $(BASEEXT).bs $(INST_ARCHAUTODIR)\$(BASEEXT).bs $(PERM_RW)
to:
$(NOECHO) $(CP_NONEMPTY) $(BASEEXT).bs $(INST_ARCHAUTODIR)\$(BASEEXT).bs $(PERM_RW)

As for duplicated 'No tests defined for ...' I have no idea but agree that it will make PDL test suite very noisy. What I have found out is that it is not specific to dmake, same trouble on cygwin.

--
kmx


On 8.1.2015 4:30, ***@optusnet.com.au wrote:

-----Original Message----- From: Ed .
Sent: Thursday, January 08, 2015 1:06 PM
To: ***@optusnet.com.au ; kmx
Cc: pdl-porters
Subject: Re: [Pdl-porters] dmake + EUMM-7.05_05 trouble


I've just pushed a change to EUMM that should suppress these warnings. Please try git latest EUMM on your code and let me know.


That takes care of the dmake noise for me.

One (very) minor quibble is that, during 'dmake test', I'm getting a tripling up of the 'No tests defined for Module::Whatever::Foo extension' warnings.
For example, with Math-MPFR-3.23:

#####################################
C:\sisyphusion\Math-MPFR-3.23>dmake test
'No tests defined for Math::MPFR::Prec extension.'
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- MPFR.bs blib\arch\auto\Math\MPFR\MPFR.bs 644
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- Prec.bs ..\blib\arch\auto\Math\MPFR\Prec\Prec.bs 644
'No tests defined for Math::MPFR::Prec extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- V.bs ..\blib\arch\auto\Math\MPFR\V\V.bs 644
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e"
"undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.
t
t/_1aaa_v.t ...............
[snip running of test suite]
t/uselongdouble.t ......... ok
All tests successful.
Files=47, Tests=729, 13 wallclock secs ( 0.17 usr + 0.03 sys = 0.20 CPU)
Result: PASS
'No tests defined for Math::MPFR::Prec extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- Prec.bs ..\blib\arch\auto\Math\MPFR\Prec\Prec.bs 644
'No tests defined for Math::MPFR::V extension.'
"C:\MinGW\Perl516\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- V.bs ..\blib\arch\auto\Math\MPFR\V\V.bs 644

C:\sisyphusion\Math-MPFR-3.23>
#####################################

That might bother purists - I'm not a purist, so I don't know.
I guess I could always add a t/test.t for the Math::MPFR::Prec and Math::MPFR::V extensions - though such a solution wouldn't scale so well wrt PDL ;-)

Cheers,
Rob

Loading...