gmt5 update to 5.1.0 and related packages

[florian@…]

I have two updates and one submission here:

• gmt5 5.0.0b -> 5.1.0
• gshhg-gmt-nc4 2.2.2 -> 2.2.4
• dcw-gmt 1.1.0 (submission, new dependency of gmt5)

The patch for gmt5 is split into two parts to change the spacing in the Portfile first.

[florian@…]

Portfile patch for gshhg-gmt-nc4

[florian@…]

Portfile patch for gmt5 (spacing only, apply first)

[florian@…]

Portfile patch for gmt5 (apply last)

[florian@…]

Portfile for dcw-gmt

[ryandesign (Ryan Carsten Schmidt)]

In attachment:Portfile-gmt5.diff​ you manually remove the optimization flags from configure.optflags and put them in -DCMAKE_C_FLAGS_RELEASE, but this isn't supposed to be necessary; the cmake portgroup is supposed to do the right thing for you.

[florian@…]

I would be happy to oblige but using the cmake portgroup is not as straightforward as it seems. When I set

PortGroup                   cmake 1.0
configure.cflags-append     -DNDEBUG -fstrict-aliasing

in Portfile, cmake is invoked with

-DCMAKE_C_FLAGS="-I/opt/local/include" -DCMAKE_C_FLAGS_RELEASE="-Os"

When I reorder:

configure.cflags-append     -DNDEBUG -fstrict-aliasing
PortGroup                   cmake 1.0

cmake is invoked with:

-DCMAKE_C_FLAGS="-I/opt/local/include" -DCMAKE_C_FLAGS_RELEASE="-Os -DNDEBUG -fstrict-aliasing"

CMake's CMAKE_C_FLAGS_RELEASE defaults to -O3 -NDEBUG but you never get this when leaving configure.cflags blank.

Btw, where does the -Os come from. I never set configure.optflags.

To get CMake's default DCMAKE_C_FLAGS_RELEASE I would have to specify this (in order):

configure.optflags          -O3
configure.cflags-append     -DNDEBUG
PortGroup                   cmake 1.0

I haven't yet seen another portfile including cmake portgroup after setting configure options. I'm puzzled.

[florian@…]

Portfile patch for gmt5 (apply last)

[florian@…]

All right, it seems the issues above were resolved in r112944 (see #41142 and #40648). What remains is that CMake's default release flags are -O3 -DNDEBUG and not -Os -DNDEBUG. Also, CMake's debug flags do not include optimization at all. With the cmake portgroup we get -Os which is not helpful. I work around this with:

if {[variant_isset debug]} {
    configure.optflags      -O0
} else {
    configure.optflags      -O3
}

Modified Portfile patch attached (attachment:Portfile-gmt5-v2.diff​).

[tenomoto (Takeshi Enomoto)]

gshhg-gmt-nc4 r113112; gmt5 (white space) r113113; dcw-gmt r113114. Florian, could you make gmt5 patch for the current (r11314) Portfile?

[florian@…]

Thanks for the new commits. I believe you forgot to set svn:keywords of dcw-gmt/Portfile though.

Florian, could you make gmt5 patch for the current (r11314) Portfile?

The file you seek is already attached: attachment:Portfile-gmt5-v2.diff​​

[tenomoto (Takeshi Enomoto)]

Florian,

I believe you forgot to set svn:keywords of dcw-gmt/Portfile though.

You mean $ $Id$ line? I never set it by myself.

The file you seek is already attached: attachment:Portfile-gmt5-v2.diff​​

I get

patching file Portfile
Hunk #1 succeeded at 2 with fuzz 1.

and the patch and svn diff are quite different. I don't want to introduce errors by manual editing.

[florian@…]

I believe you forgot to set svn:keywords of dcw-gmt/Portfile though.

You mean $ $Id$ line? I never set it by myself.

Just set svn:keywords properties and the line will expand to include revision etc.:

svn propset svn:keywords Id dcw-gmt/Portfile

I get

patching file Portfile
Hunk #1 succeeded at 2 with fuzz 1.

and the patch and svn diff are quite different. I don't want to introduce errors by manual editing.

Oh, I see. That is because of the changed $Id$-line due to your 1st commit. The patch message you got is just a warning. The patch has been applied successfully. Nevertheless, I'll attach a new diff: attachment:Portfile-gmt5-v3.diff​

[florian@…]

Portfile patch for gmt5 (apply last)

[tenomoto (Takeshi Enomoto)]

Do you have any reason not to include fftw3 in default_variants?

[florian@…]

Hi, the reason is that only few people will use GMT's DFT modules. And those who actually do probably don't need fftw3. Especially on OSX, since GMT can fall back to the highly optimized Accelerate framework when fftw3 is not available. Besides GMT needs the single precision fftw3 which is uncommon. Maybe we can reword the variant description to make it more cleat to the user: "Optional support for FFTW-3 library".

[tenomoto (Takeshi Enomoto)]

OK. I leave it as an option and edit the description.

[tenomoto (Takeshi Enomoto)]

Committed the update for 5.1.0 in r113125.