[Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

[Chris Marshall]

...and should be appearing at a CPAN mirror near you.

This release is part of the continuing run-up to an official
PDL-2.008 release. We welcome bugs fixed, documentation
contributions, tutorials, anything to help prep and polish the
distribution for release.

NOTE: The original plan was for a January release but there
are a number of key issues that need to be addressed which
can't be completed by 31-Jan. Plan on a Feb 2015 arrival.

Enjoy,
Chris

Release Notes for PDL 2.007_09 --------------------------

+---------------------------------------------------------------+
| BE WARNED: This release includes an update to the internal, |
| C-level PDL API for PDL versions 2.006 and earlier. This |
| will require that you re-build any PP or XS modules. Do not |
| upgrade or install over an existing PDL installation unless |
| you are prepared to do so!!! |
+---------------------------------------------------------------+
* Counting down to a PDL-2.008 release this February 2015
* Another quick CPAN developers release
- It is a snapshot of the current git development tree
and everything may not work correctly or have complete
documentation.
- These release notes may not be fully complete. Please
see Changes (from the git log) for full details.
- All tests may not pass, especially ones corresponding
to issues in Known_problems.
- Manual build/install is recommended although the
cpan shell may be used by specifying the distribution
cpan> get CHM/PDL-2.007_09.tar.gz
cpan> make CHM/PDL-2.007_09.tar.gz
cpan> test CHM/PDL-2.007_09.tar.gz
cpan> look CHM/PDL-2.007_09.tar.gz
* perl 5.10.x is now the minimum version of perl supported for
this release. Please test.
* Much clean up of the EU::MM build process by Ed.

[s***@optusnet.com.au]

From: Chris Marshall
Sent: Friday, January 30, 2015 6:07 AM

This release is part of the continuing run-up to an official PDL-2.008
release.

There's a problem with the Lib/GIS/Proj/Makefile.PL (which has been
extensively re-organized) on Windows.

Instead of creating Proj.bs and Proj.def during the build I now get
package_name.bs and ackage_name.def.
It's the "ackage_name.def" that's the problem - rename it to
"package_name.def" and the build succeeds.

Looking at the diff between the 2 Makefile.PLs it's hard to spot what's
responsible. (Maybe we need to look in EU-MM, for which I'm using version
7.04.)
Perhaps the author of the changes has an idea about this ? Otherwise I'll
take a look tonight.

For the moment I'm just using the 2.007_08 Makefile.PL - which seems to be
working fine.

The other thing is that I can't push/pull to/from the PDL git repo as it
won't accept my password any more.
Am I supposed to have changed my sourceforge password recently ?

Cheers,
Rob

[Ed]

Hi Rob,

If you can bear to, could you try the git latest EUMM? Otherwise, any
information you can provide to fix it will be welcome. Also, guidance on how
to install the Proj library on my machine will be welcome, as I'm not really
exercising that installation here.

Cheers,
Ed

-----Original Message-----
From: ***@optusnet.com.au
Sent: Friday, January 30, 2015 1:15 AM
To: Chris Marshall ; ***@jach.hawaii.edu ; pdl-porters
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN


From: Chris Marshall
Sent: Friday, January 30, 2015 6:07 AM

This release is part of the continuing run-up to an official PDL-2.008
release.

There's a problem with the Lib/GIS/Proj/Makefile.PL (which has been
extensively re-organized) on Windows.

Instead of creating Proj.bs and Proj.def during the build I now get
package_name.bs and ackage_name.def.
It's the "ackage_name.def" that's the problem - rename it to
"package_name.def" and the build succeeds.

Looking at the diff between the 2 Makefile.PLs it's hard to spot what's
responsible. (Maybe we need to look in EU-MM, for which I'm using version
7.04.)
Perhaps the author of the changes has an idea about this ? Otherwise I'll
take a look tonight.

For the moment I'm just using the 2.007_08 Makefile.PL - which seems to be
working fine.

The other thing is that I can't push/pull to/from the PDL git repo as it
won't accept my password any more.
Am I supposed to have changed my sourceforge password recently ?

Cheers,
Rob

[Chris Marshall]

On cygwin I usually build from source. For linux you should be able to
get via a package manager. For windows, talk to Rob. :-)

--Chris

Post by Ed
Hi Rob,
If you can bear to, could you try the git latest EUMM? Otherwise, any
information you can provide to fix it will be welcome. Also, guidance
on how to install the Proj library on my machine will be welcome, as
I'm not really exercising that installation here.
Cheers,
Ed

[s***@optusnet.com.au]

-----Original Message-----
From: Chris Marshall
Sent: Friday, January 30, 2015 11:13 PM
To: Ed
Cc: ***@optusnet.com.au ; pdl-porters
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

Post by Chris Marshall
On cygwin I usually build from source. For linux you should be able to
get via a package manager. For windows, talk to Rob. :-)

On windows kmx also provides builds of strawberry-5.20 that come with the
proj library. I think those builds also ship with a build of PDL that
includes proj support.
Grab either
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-32bit-PDL.zip
or
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-64bit-PDL.zip

Both kmx and I build Proj in the msys shell, by running the usual
'./configure', 'make', 'make check', 'make install' mantra that nix folk are
familiar with.
I generally build static libraries (--disable-shared --enable-static) but
strawberry generally provides shared libraries
(--enable-shared --disable-static).

In the perldl.conf that I use for 32-bit builds I have:

WITH_PROJ => undef, # Leave it up to PDL to decide
PROJ_LIBS => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/lib']
: [ 'C:/_32/msys_482/1.0/local/lib'],
PROJ_INC => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/include']
: [ 'C:/_32/msys_482/1.0/local/include'],

However, my $Config{libpth} also includes the pertinent lib location - so I
don't know whether I really need to specify PROJ_LIBS. (The
Lib/GIS/Proj/Makefile.PL accesses $Config{libpth} and should locate the proj
library that way.)
I think kmx utilises the Lib/GIS/Proj/Makefile.PL's use of $Config{usrinc}
for locating the headers, but I don't. I'll either be relying on PROJ_INC or
$ENV{CPATH} to locate them. (Not sure which, offhand.)

IIRC the latest version of Proj doesn't install projects.h (as that file is
no longer considered part of the public API). However, Proj.pd still wants
to include that file.
My workaround has been to manually install (copy) projects.h to the same
location into which proj_api.h gets installed.

I notice that strawberry doesn't seem to provide projects.h so I guess kmx
might have come up with a different (and probably better) hack.

As regards proj-4.7.0 I have the following note:

############################
In pj_mutex.c I changed
#ifdef MUTEX_pthread
to
#if defined(MUTEX_pthread) && !defined(MUTEX_win32)
Otherwise I get "pthread.h" (which I don't have) included.
############################

I'm not sure whether the same needs to be done for later proj versions.
I haven't even checked to see what the latest version is ... the most recent
I've built is 4.8.0.

That's about it, I think.

Cheers,
Rob

[kmx]

-----Original Message----- From: Chris Marshall
Sent: Friday, January 30, 2015 11:13 PM
To: Ed
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

On cygwin I usually build from source. For linux you should be able to
get via a package manager. For windows, talk to Rob. :-)

On windows kmx also provides builds of strawberry-5.20 that come with the
proj library. I think those builds also ship with a build of PDL that
includes proj support.
Grab either
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-32bit-PDL.zip
or
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-64bit-PDL.zip
Both kmx and I build Proj in the msys shell, by running the usual
'./configure', 'make', 'make check', 'make install' mantra that nix folk
are familiar with.
I generally build static libraries (--disable-shared --enable-static) but
strawberry generally provides shared libraries (--enable-shared
--disable-static).
WITH_PROJ => undef, # Leave it up to PDL to decide
PROJ_LIBS => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/lib']
: [ 'C:/_32/msys_482/1.0/local/lib'],
PROJ_INC => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/include']
: [ 'C:/_32/msys_482/1.0/local/include'],
However, my $Config{libpth} also includes the pertinent lib location - so
I don't know whether I really need to specify PROJ_LIBS. (The
Lib/GIS/Proj/Makefile.PL accesses $Config{libpth} and should locate the
proj library that way.)
I think kmx utilises the Lib/GIS/Proj/Makefile.PL's use of
$Config{usrinc} for locating the headers, but I don't. I'll either be
relying on PROJ_INC or $ENV{CPATH} to locate them. (Not sure which,
offhand.)
IIRC the latest version of Proj doesn't install projects.h (as that file
is no longer considered part of the public API). However, Proj.pd still
wants to include that file.
My workaround has been to manually install (copy) projects.h to the same
location into which proj_api.h gets installed.
I notice that strawberry doesn't seem to provide projects.h so I guess
kmx might have come up with a different (and probably better) hack.

Strawberry perl has $Config{usrinc} set to
'c:\whatever\strawberry\perl\rootdir\c\include' which might be the hack in
question.

Anyway PDL (PDL::GIS::Proj) should correctly detect proj library bundled
with PDL edition of strawberry perl (no config hacking, no special
parameters), if not it is a regression. I have not tested 2.007_09 yet but
2.007_08 worked fine.

--
kmx

[kmx]

Post by kmx

-----Original Message----- From: Chris Marshall
Sent: Friday, January 30, 2015 11:13 PM
To: Ed
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

On cygwin I usually build from source. For linux you should be able to
get via a package manager. For windows, talk to Rob. :-)

On windows kmx also provides builds of strawberry-5.20 that come with
the proj library. I think those builds also ship with a build of PDL
that includes proj support.
Grab either
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-32bit-PDL.zip
or
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-64bit-PDL.zip
Both kmx and I build Proj in the msys shell, by running the usual
'./configure', 'make', 'make check', 'make install' mantra that nix folk
are familiar with.
I generally build static libraries (--disable-shared --enable-static)
but strawberry generally provides shared libraries (--enable-shared
--disable-static).
WITH_PROJ => undef, # Leave it up to PDL to decide
PROJ_LIBS => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/lib']
: [ 'C:/_32/msys_482/1.0/local/lib'],
PROJ_INC => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/include']
: [ 'C:/_32/msys_482/1.0/local/include'],
However, my $Config{libpth} also includes the pertinent lib location -
so I don't know whether I really need to specify PROJ_LIBS. (The
Lib/GIS/Proj/Makefile.PL accesses $Config{libpth} and should locate the
proj library that way.)
I think kmx utilises the Lib/GIS/Proj/Makefile.PL's use of
$Config{usrinc} for locating the headers, but I don't. I'll either be
relying on PROJ_INC or $ENV{CPATH} to locate them. (Not sure which,
offhand.)
IIRC the latest version of Proj doesn't install projects.h (as that file
is no longer considered part of the public API). However, Proj.pd still
wants to include that file.
My workaround has been to manually install (copy) projects.h to the same
location into which proj_api.h gets installed.
I notice that strawberry doesn't seem to provide projects.h so I guess
kmx might have come up with a different (and probably better) hack.

Strawberry perl has $Config{usrinc} set to
'c:\whatever\strawberry\perl\rootdir\c\include' which might be the hack
in question.
Anyway PDL (PDL::GIS::Proj) should correctly detect proj library bundled
with PDL edition of strawberry perl (no config hacking, no special
parameters), if not it is a regression. I have not tested 2.007_09 yet
but 2.007_08 worked fine.

2.007_09 fails like this:

"C:\tmp32\perl\bin\perl.exe" "-I..\..\..\blib\arch" "-I..\..\..\blib\lib"
"-MPDL::PP qw/ackage_name ackage_name Proj/" Proj.pd
cp Proj.pm ..\..\..\blib\lib/Proj.pm
Running Mkbootstrap for ackage_name ()
"C:\tmp32\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644
"package_name.bs"
"C:\tmp32\perl\bin\perl.exe" "C:\tmp32\perl\lib\ExtUtils\xsubpp" -typemap
"C:\tmp32\perl\lib\ExtUtils\typemap" -typemap
"C:/tmp32/data/.cpanm/work/1422633453.17716/PDL-2.007_09/Basic/Core/typemap.pdl"
Proj.xs > Proj.xsc && "C:\tmp32\perl\bin\perl.exe" -MExtUtils::Command -e
mv -- Proj.xsc Proj.c
gcc -c
"-IC:/tmp32/data/.cpanm/work/1422633453.17716/PDL-2.007_09/Basic/Core"
-IC:\tmp32\c\include -Iinclude/ -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv
-fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"1.32\"
-DXS_VERSION=\"1.32\" "-IC:\tmp32\perl\lib\CORE" Proj.c
"C:\tmp32\perl\bin\perl.exe" -MExtUtils::Mksymlists \
-e "Mksymlists('NAME'=>\"ackage_name\", 'DLBASE' => 'package_name',
'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);"
dlltool --def package_name.def --output-exp dll.exp
dlltool: Can't open def file: package_name.def
dmake: Error code 129, while making
'..\..\..\blib\arch\auto\ackage_name\package_name.xs.dll'
dmake: Error code 255, while making 'subdirs'
dmake: Error code 255, while making 'subdirs'
dmake.exe: Error code 255, while making 'subdirs'
FAIL
! Installing
http://cpan.metacpan.org/authors/id/C/CH/CHM/PDL-2.007_09.tar.gz failed.
See C:\tmp32\data\.cpanm\work\1422633453.17716\build.log for details. Retry
with --force to force install it.

which seems to be the trouble mentioned by Rob earlier in this thread

--
kmx

[Ed]

Rob's patch (applied on git master earlier - good catch, Rob!) should fix
this - suggest updating and retrying.

If anyone's interested, what happened was I changed the @pack from
(excerpted): ('Proj', $package_name) to qw(Proj $package_name). Therefore,
the literal text '$package_name' was going through to make. Make treats as
variables to expand either $(variable) OR $c where c is one character. It
expanded the $p above to nothing, leaving 'ackage_name', hence the messages
seen.

Ed

-----Original Message-----
From: kmx
Sent: Friday, January 30, 2015 4:25 PM
To: pdl-***@jach.hawaii.edu
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

Post by kmx

-----Original Message----- From: Chris Marshall
Sent: Friday, January 30, 2015 11:13 PM
To: Ed
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

On cygwin I usually build from source. For linux you should be able to
get via a package manager. For windows, talk to Rob. :-)

On windows kmx also provides builds of strawberry-5.20 that come with the
proj library. I think those builds also ship with a build of PDL that
includes proj support.
Grab either
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-32bit-PDL.zip
or
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-64bit-PDL.zip
Both kmx and I build Proj in the msys shell, by running the usual
'./configure', 'make', 'make check', 'make install' mantra that nix folk
are familiar with.
I generally build static libraries (--disable-shared --enable-static) but
strawberry generally provides shared libraries
(--enable-shared --disable-static).
WITH_PROJ => undef, # Leave it up to PDL to decide
PROJ_LIBS => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/lib']
: [ 'C:/_32/msys_482/1.0/local/lib'],
PROJ_INC => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/include']
: [ 'C:/_32/msys_482/1.0/local/include'],
However, my $Config{libpth} also includes the pertinent lib location - so
I don't know whether I really need to specify PROJ_LIBS. (The
Lib/GIS/Proj/Makefile.PL accesses $Config{libpth} and should locate the
proj library that way.)
I think kmx utilises the Lib/GIS/Proj/Makefile.PL's use of
$Config{usrinc} for locating the headers, but I don't. I'll either be
relying on PROJ_INC or $ENV{CPATH} to locate them. (Not sure which,
offhand.)
IIRC the latest version of Proj doesn't install projects.h (as that file
is no longer considered part of the public API). However, Proj.pd still
wants to include that file.
My workaround has been to manually install (copy) projects.h to the same
location into which proj_api.h gets installed.
I notice that strawberry doesn't seem to provide projects.h so I guess
kmx might have come up with a different (and probably better) hack.

Strawberry perl has $Config{usrinc} set to
'c:\whatever\strawberry\perl\rootdir\c\include' which might be the hack in
question.
Anyway PDL (PDL::GIS::Proj) should correctly detect proj library bundled
with PDL edition of strawberry perl (no config hacking, no special
parameters), if not it is a regression. I have not tested 2.007_09 yet but
2.007_08 worked fine.

2.007_09 fails like this:

"C:\tmp32\perl\bin\perl.exe" "-I..\..\..\blib\arch" "-I..\..\..\blib\lib"
"-MPDL::PP qw/ackage_name ackage_name Proj/" Proj.pd
cp Proj.pm ..\..\..\blib\lib/Proj.pm
Running Mkbootstrap for ackage_name ()
"C:\tmp32\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644
"package_name.bs"
"C:\tmp32\perl\bin\perl.exe" "C:\tmp32\perl\lib\ExtUtils\xsubpp" -typemap
"C:\tmp32\perl\lib\ExtUtils\typemap" -typemap
"C:/tmp32/data/.cpanm/work/1422633453.17716/PDL-2.007_09/Basic/Core/typemap.pdl"
Proj.xs > Proj.xsc && "C:\tmp32\perl\bin\perl.exe" -MExtUtils::Command -e
mv -- Proj.xsc Proj.c
gcc -c
"-IC:/tmp32/data/.cpanm/work/1422633453.17716/PDL-2.007_09/Basic/Core"
-IC:\tmp32\c\include -Iinclude/ -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv
-fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"1.32\"
-DXS_VERSION=\"1.32\" "-IC:\tmp32\perl\lib\CORE" Proj.c
"C:\tmp32\perl\bin\perl.exe" -MExtUtils::Mksymlists \
-e "Mksymlists('NAME'=>\"ackage_name\", 'DLBASE' => 'package_name',
'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);"
dlltool --def package_name.def --output-exp dll.exp
dlltool: Can't open def file: package_name.def
dmake: Error code 129, while making
'..\..\..\blib\arch\auto\ackage_name\package_name.xs.dll'
dmake: Error code 255, while making 'subdirs'
dmake: Error code 255, while making 'subdirs'
dmake.exe: Error code 255, while making 'subdirs'
FAIL
! Installing
http://cpan.metacpan.org/authors/id/C/CH/CHM/PDL-2.007_09.tar.gz failed.
See C:\tmp32\data\.cpanm\work\1422633453.17716\build.log for details. Retry
with --force to force install it.

which seems to be the trouble mentioned by Rob earlier in this thread

--
kmx

[kmx]

Yes, the latest git version builds fine.

As I was testing on 64bit MS Windows I have also investigated 2 strange
compiler warnings and ended up with 2 small fixes (64-bitness related - see
git log).

--
kmx

Post by Ed
Rob's patch (applied on git master earlier - good catch, Rob!) should fix
this - suggest updating and retrying.
(excerpted): ('Proj', $package_name) to qw(Proj $package_name).
Therefore, the literal text '$package_name' was going through to make.
Make treats as variables to expand either $(variable) OR $c where c is
one character. It expanded the $p above to nothing, leaving
'ackage_name', hence the messages seen.
Ed
-----Original Message----- From: kmx
Sent: Friday, January 30, 2015 4:25 PM
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

Post by kmx

-----Original Message----- From: Chris Marshall
Sent: Friday, January 30, 2015 11:13 PM
To: Ed
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

On cygwin I usually build from source. For linux you should be able to
get via a package manager. For windows, talk to Rob. :-)

On windows kmx also provides builds of strawberry-5.20 that come with
the proj library. I think those builds also ship with a build of PDL
that includes proj support.
Grab either
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-32bit-PDL.zip
or
http://strawberryperl.com/download/5.20.1.1/strawberry-perl-5.20.1.1-64bit-PDL.zip
Both kmx and I build Proj in the msys shell, by running the usual
'./configure', 'make', 'make check', 'make install' mantra that nix
folk are familiar with.
I generally build static libraries (--disable-shared --enable-static)
but strawberry generally provides shared libraries (--enable-shared
--disable-static).
WITH_PROJ => undef, # Leave it up to PDL to decide
PROJ_LIBS => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/lib']
: [ 'C:/_32/msys_482/1.0/local/lib'],
PROJ_INC => $] < 5.02
? [ 'C:/MinGW/msys/1.0/local/include']
: [ 'C:/_32/msys_482/1.0/local/include'],
However, my $Config{libpth} also includes the pertinent lib location -
so I don't know whether I really need to specify PROJ_LIBS. (The
Lib/GIS/Proj/Makefile.PL accesses $Config{libpth} and should locate the
proj library that way.)
I think kmx utilises the Lib/GIS/Proj/Makefile.PL's use of
$Config{usrinc} for locating the headers, but I don't. I'll either be
relying on PROJ_INC or $ENV{CPATH} to locate them. (Not sure which,
offhand.)
IIRC the latest version of Proj doesn't install projects.h (as that
file is no longer considered part of the public API). However, Proj.pd
still wants to include that file.
My workaround has been to manually install (copy) projects.h to the
same location into which proj_api.h gets installed.
I notice that strawberry doesn't seem to provide projects.h so I guess
kmx might have come up with a different (and probably better) hack.

Strawberry perl has $Config{usrinc} set to
'c:\whatever\strawberry\perl\rootdir\c\include' which might be the hack
in question.
Anyway PDL (PDL::GIS::Proj) should correctly detect proj library bundled
with PDL edition of strawberry perl (no config hacking, no special
parameters), if not it is a regression. I have not tested 2.007_09 yet
but 2.007_08 worked fine.

"C:\tmp32\perl\bin\perl.exe" "-I..\..\..\blib\arch" "-I..\..\..\blib\lib"
"-MPDL::PP qw/ackage_name ackage_name Proj/" Proj.pd
cp Proj.pm ..\..\..\blib\lib/Proj.pm
Running Mkbootstrap for ackage_name ()
"C:\tmp32\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644
"package_name.bs"
"C:\tmp32\perl\bin\perl.exe" "C:\tmp32\perl\lib\ExtUtils\xsubpp" -typemap
"C:\tmp32\perl\lib\ExtUtils\typemap" -typemap
"C:/tmp32/data/.cpanm/work/1422633453.17716/PDL-2.007_09/Basic/Core/typemap.pdl"
Proj.xs > Proj.xsc && "C:\tmp32\perl\bin\perl.exe" -MExtUtils::Command -e
mv -- Proj.xsc Proj.c
gcc -c
"-IC:/tmp32/data/.cpanm/work/1422633453.17716/PDL-2.007_09/Basic/Core"
-IC:\tmp32\c\include -Iinclude/ -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv
-fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"1.32\"
-DXS_VERSION=\"1.32\" "-IC:\tmp32\perl\lib\CORE" Proj.c
"C:\tmp32\perl\bin\perl.exe" -MExtUtils::Mksymlists \
-e "Mksymlists('NAME'=>\"ackage_name\", 'DLBASE' => 'package_name',
'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);"
dlltool --def package_name.def --output-exp dll.exp
dlltool: Can't open def file: package_name.def
dmake: Error code 129, while making
'..\..\..\blib\arch\auto\ackage_name\package_name.xs.dll'
dmake: Error code 255, while making 'subdirs'
dmake: Error code 255, while making 'subdirs'
dmake.exe: Error code 255, while making 'subdirs'
FAIL
! Installing
http://cpan.metacpan.org/authors/id/C/CH/CHM/PDL-2.007_09.tar.gz failed.
See C:\tmp32\data\.cpanm\work\1422633453.17716\build.log for details. Retry
with --force to force install it.
which seems to be the trouble mentioned by Rob earlier in this thread
--
kmx
_______________________________________________
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]

-----Original Message-----
From: kmx
Sent: Saturday, January 31, 2015 1:58 AM

Post by kmx

Post by s***@optusnet.com.au
I notice that strawberry doesn't seem to provide projects.h so I guess
kmx might have come up with a different (and probably better) hack.

Strawberry perl has $Config{usrinc} set to
'c:\whatever\strawberry\perl\rootdir\c\include' which might be the hack in
question.
Anyway PDL (PDL::GIS::Proj) should correctly detect proj library bundled
with PDL edition of strawberry perl (no config hacking, no special
parameters), if not it is a regression. I have not tested 2.007_09 yet but
2.007_08 worked fine.

The thing is that Strawberry doesn't provide projects.h, yet the generated
Proj.xs definitely contains:

#include "projects.h"

so where does "projects.h" come from ?
The answer is that the file is now included with the PDL source distro in
Lib/GIS/Proj/include.
It's the actual projects.h from the Proj source distro.
I probably knew about that at some stage, but forgot because my hack means
that I don't need that PDL hack.

I think it's intended only as a temporary fix, but it seems to be working ok
thus far.
A problem arises if changes in later versions of the Proj library render
Lib/GIS/Proj/include/projects.h incompatible.

Cheers,
Rob

[Chris Marshall]

I'm not seeing problems here. Are you able to login to your sf.net user
account?
If so the problem would seem to be more git specific.

--Chris

Post by s***@optusnet.com.au
The other thing is that I can't push/pull to/from the PDL git repo as
it won't accept my password any more.
Am I supposed to have changed my sourceforge password recently ?
Cheers,
Rob

[s***@optusnet.com.au]

-----Original Message-----
From: Chris Marshall
Sent: Friday, January 30, 2015 11:11 PM
To: ***@optusnet.com.au ; pdl-porters
Subject: Re: [Pdl-porters] CHM/PDL-2.007_09.tar.gz released to CPAN

Post by Chris Marshall
I'm not seeing problems here. Are you able to login to your sf.net user
account?

I've finally got it fixed this morning.
It was just a matter of re-setting my password - with some obstacles along
the way.
All is now fine until next time.

Thanks for applying the patch.

Cheers,
Rob

[s***@optusnet.com.au]

-----Original Message-----

Post by s***@optusnet.com.au

This release is part of the continuing run-up to an official PDL-2.008
release.

There's a problem with the Lib/GIS/Proj/Makefile.PL (which has been
extensively re-organized) on Windows.

Changes weren't as extensive as I first thought.
Could someone please apply the attached patch to Lib/GIS/Proj/Makefile.PL
(assuming it looks ok).

The PDL git repo still refuses to have anything to do with me.

Cheers,
Rob