ldas-tools @2.4.2 Updated for latest release of software

[emaros]

This update is for ldas-tools 2.4.2 using the Xcode 7.0

[emaros]

Patch file for AtExit.cc needed for Xcode 7.0

[emaros]

Patch file for TaskThread.cc needed for Xcode 7.0

[ryandesign (Ryan Carsten Schmidt)]

Thanks.

[skymoo (Adam Mercer)]

If the patchfiles are going to be committed to SVN you don't need to include the checksums in the Portfile, these are only needed if they are downloaded.

However, if I remove the checksums for the patchfiles then this still fails for me, on El Capitan, with the following:

:info:build     /usr/bin/python ./framecpp_sample.py
:info:build Traceback (most recent call last):
:info:build   File "./framecpp_sample.py", line 6, in <module>
:info:build     import frameCPP
:info:build   File "/opt/local/var/macports/build/_Users_ram_macports_ports_science_ldas-tools/ldas-tools/work/ldas-tools-2.4.2/libraries/framecpp/src/OOInterface/frameCPP.py", line 33, in <module>
:info:build     _frameCPP = swig_import_helper()
:info:build   File "/opt/local/var/macports/build/_Users_ram_macports_ports_science_ldas-tools/ldas-tools/work/ldas-tools-2.4.2/libraries/framecpp/src/OOInterface/frameCPP.py", line 25, in swig_import_helper
:info:build     import _frameCPP
:info:build ImportError: dlopen(/opt/local/var/macports/build/_Users_ram_macports_ports_science_ldas-tools/ldas-tools/work/ldas-tools-2.4.2/libraries/framecpp/src/OOInterface/.libs/_frameCPP.so, 2): Library not loaded: /opt/local/lib/libframecpp.6.dylib
:info:build   Referenced from: /opt/local/var/macports/build/_Users_ram_macports_ports_science_ldas-tools/ldas-tools/work/ldas-tools-2.4.2/libraries/framecpp/src/OOInterface/.libs/_frameCPP.so
:info:build   Reason: image not found

I'll attach the full build log. I think the problem here is that the system python is being used, so the appropriate libraries can't be found. I think you need to specify that the MacPorts python should be used (using configure.python), otherwise it's just going to use whatever python is in the environment.

[skymoo (Adam Mercer)]

Cc Me!

[emaros]

Looking into the issue, I have discovered that what I need is to specify the line

configure.python "python${v}"

What would be most ideal is if I could fully qualify the path to the version specific python executable. Ideas on how to do this? Also, when I submit the patch, should it replace the current Portfile patch or be relative to the existing patch.

[skymoo (Adam Mercer)]

Replying to ed.maros@…:

What would be most ideal is if I could fully qualify the path to the version specific python executable. Ideas on how to do this?

Would the following work?

configure.python ${prefix}/bin/python${v}

Also, when I submit the patch, should it replace the current Portfile patch or be relative to the existing patch.

Relative to what's in SVN would probably make more sense.

[emaros]

Replying to ram@…:

Replying to ed.maros@…:

What would be most ideal is if I could fully qualify the path to the version specific python executable. Ideas on how to do this?

Would the following work?

configure.python ${prefix}/bin/python${v}

Trying this now. I was just concerned that it wouldn't since I need the value at configure time.

Also, when I submit the patch, should it replace the current Portfile patch or be relative to the existing patch.

Relative to what's in SVN would probably make more sense.

[emaros]

I have uploaded a new patch for the Portfile to address the ElCapitan issue. I have added a single line which directs the build to use the MacPorts version specific Python interpreter as directed by the variant option.

[skymoo (Adam Mercer)]

Replying to ed.maros@…:

I have uploaded a new patch for the Portfile to address the ElCapitan issue. I have added a single line which directs the build to use the MacPorts version specific Python interpreter as directed by the variant option.

The checksums for the patches are still present and there is no python interpreter specified, are you sure this is the new patch?

[emaros]

Replying to ram@…:

Replying to ed.maros@…:

I have uploaded a new patch for the Portfile to address the ElCapitan issue. I have added a single line which directs the build to use the MacPorts version specific Python interpreter as directed by the variant option.

The checksums for the patches are still present and there is no python interpreter specified, are you sure this is the new patch?

Sorry. I was working on too many systems. I have uploaded the modified patch. It still has the checksums of the patches because I was unable to do a port install without them. Perhaps I do not have my system configured properly for testing purposes. My model for testing is that I have the files in a local directory and do 'sudo port install'. Is this 'forcing' me into having to 'download' the patches (which I accomplish by copying them to the appropriate distfiles location)?

[skymoo (Adam Mercer)]

If you put the patchfiles into a sub-directory called files at the same level as the Portfile then they should be found and you won't need the checksums.

I do have a question about the following hunk in the patch:

@@ -30,7 +40,7 @@
     configure.args-append --disable-cxx11
 }
 
-depends_lib    path:lib/libssl.dylib:openssl \
+depends_lib    port:openssl \
                port:zlib \
                port:bzip2 \
                port:flex
@@ -47,17 +57,19 @@

The path dependency for libssl.dylib was added so that libressl could be used instead of openssl, as you've changed this back is there some reason that libressl can't be used to satisfy the libssl dependency?

Also there is inconsistent whitespace usage, for example mixed tab and space usage. Can you use one or the other?

I have a test build going now and I'll report back on whether that builds or not once the test has completed.

[skymoo (Adam Mercer)]

Replying to ram@…:

I have a test build going now and I'll report back on whether that builds or not once the test has completed.

The build completed successfully.

[emaros]

Replying to ram@…:

Replying to ram@…:

I have a test build going now and I'll report back on whether that builds or not once the test has completed.

The build completed successfully.

Based on your suggestions, I am making some corrections that I will upload after verification.

[emaros]

New version has been uploaded with consistent white spaces, no checksums for patches and removal of unneeded openssl library dependency.

[skymoo (Adam Mercer)]

Are you sure that ssl is unneeded as libframecpp8.dylib, for example, is linked against libcrypto from openssl:

$ otool -L libframecpp8.dylib
libframecpp8.dylib:
	/opt/local/lib/libframecpp8.4.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libframecpp7.2.dylib (compatibility version 3.0.0, current version 3.1.0)
	/opt/local/lib/libframecpp6.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libframecpp4.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libframecpp3.3.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libframecppcmn.4.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
$ port provides /opt/local/lib/libcrypto.1.0.0.dylib
/opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl
$

[emaros]

Replying to ram@…:

Are you sure that ssl is unneeded as libframecpp8.dylib, for example, is linked against libcrypto from openssl:

$ otool -L libframecpp8.dylib
libframecpp8.dylib:
	/opt/local/lib/libframecpp8.4.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libframecpp7.2.dylib (compatibility version 3.0.0, current version 3.1.0)
	/opt/local/lib/libframecpp6.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libframecpp4.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libframecpp3.3.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libframecppcmn.4.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
$ port provides /opt/local/lib/libcrypto.1.0.0.dylib
/opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl
$

Good catch. I will put it back. Question is system version vs MacPorts version.

[skymoo (Adam Mercer)]

The MacPorts version should be used but use the path:lib/libssl.dylib:openssl style dependency so that either libressl or openssl can provide dependency, unless libressl can't be used for some reason.

[emaros]

Modifications to the Portfile

[emaros]

New version with the proper ssl library reference

[skymoo (Adam Mercer)]

Looks good to me.

Ryan: As this is assigned to you do you have any comments or concerns?

[ryandesign (Ryan Carsten Schmidt)]

Committed in r141069.

I removed the quotes around ${prefix}/bin/python${v} because they are not needed.

I made the python27 variant the default only if the other python variant was not already selected. See PortfileRecipes#default_variants.

I changed "configure.args-strsed s/--disable-python/--enable-python/" which had already been in the portfile to "configure.args-replace --disable-python --enable-python"