Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP Let the GMT/MEX toolbox be an optional supplement in the main GMT project #4246

Open
wants to merge 75 commits into
base: master
Choose a base branch
from

Conversation

PaulWessel
Copy link
Member

This is the first import of files and settings that seems relevant from the old autoconf/Makefile-driven gmtmex project.

First goal is to have this not break regular GMT built when GMT_BUILD_GMTMEX is not set. Looks like I have achieved that.

… gmtmex

First goal is to have this no break regular GMT when GMT_BUILD_GMTMEX is not set.
@PaulWessel
Copy link
Member Author

This PR will set the right matlab/mex libraries and add them as optiona libraries, and add the mex include dir as an included dir.

*  Build module links         : 
*  MATLAB Application         : /Applications/MATLAB_R2019a.app
*  MATLAB include dir         : /Applications/MATLAB_R2019a.app/extern/include
*  MATLAB MEX library         : /Applications/MATLAB_R2019a.app/bin/maci64/libmex.dylib
*  MATLAB MX library          : /Applications/MATLAB_R2019a.app/bin/maci64/libmx.dylib
*  Found Ghostscript (gs)     : yes (9.50)

It seems to build the two object files under dbuild/src:

ls CMakeFiles/supplements.dir/gmtmex/
gmtmex.c.o		gmtmex_parser.c.o

but there are challenges since these are not really supplemental modules like meca and velo, but only library stubs apart from an executable (like gmt). So need to make some changes. First up are these failures

[7/269] Generating gmt_supplements_moduleinfo.h
CMake Warning at /Users/pwessel/GMTdev/gmt-dev/cmake/modules/GmtGenExtraHeaders.cmake:90 (message):
  THIS_MODULE_CLASSIC_NAME is empty in gmtmex/gmtmex.c
Call Stack (most recent call first):
  /Users/pwessel/GMTdev/gmt-dev/cmake/modules/GmtGenExtraHeaders.cmake:131 (gen_gmt_moduleinfo_h)

which is true since these are not modules. Thoughts on how to bypass that step for this supplement, @seisman ? Maybe a getter plan is to add the gmtmex_parser.c to the main GMT library building instead of having it inside the supplements.so? So conditionally add that file to libgmt.dylib. Can I do that inside the gmtmex CMakeLists.txt file?

Comment on lines 29 to 31
set (SUPPL_PROGS_SRCS gmtmex.c gmtmex_parser.c)
set (SUPPL_HEADERS gmtmex.h)
set (SUPPL_LIB_SRCS ${SUPPL_PROGS_SRCS})
Copy link
Member

@seisman seisman Sep 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may work:

Suggested change
set (SUPPL_PROGS_SRCS gmtmex.c gmtmex_parser.c)
set (SUPPL_HEADERS gmtmex.h)
set (SUPPL_LIB_SRCS ${SUPPL_PROGS_SRCS})
set (SUPPL_HEADERS gmtmex.h)
set (SUPPL_LIB_SRCS gmtmex.c gmtmex_parser.c)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with header and parser. But gmtmex.c is like gmt.c and is to become a stand-alone executable. So perhaps just parser?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gmtmex.c is not a module, so can't be in SUPPL_PROGS_SRCS. Perhaps need to define a new cmake variable, and also update src/CMakeLists to be able to build stand-alone programs.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I will leave it off for now since it is different.

@PaulWessel
Copy link
Member Author

So this commit that you suggested causes no errors (I am not involving gmtmex.c yet and its product), and the 4 experted GMTMEX functions ended up in supplements.so:

nm -gU supplements.so | grep GMTMEX
00000000001887b0 T _GMTMEX_Get_Object
00000000001844d0 T _GMTMEX_Set_Object
0000000000184360 T _GMTMEX_objecttype
0000000000184330 T _GMTMEX_print_func

Since gmtmex certainly is "supplemental" that that is probably fine. I think maybe more things from gmtmex.c could go into the parser so that we could have as small a driver void mexFunction (int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
as possible.

@PaulWessel
Copy link
Member Author

Hi @seisman, I am close (picking up on this PR again). Since it is not a supplement it wont be added to SUPPL_EXTRA_DIRS, and instead, like the MB glue, I just add it to libgmt via

if (GMT_BUILD_GMTMEX)
	set (GMT_GMTMEX_SRCS gmtmex/gmtmex_parser.c gmtmex/gmtmex.c gmtmex/gmtmex.h)
endif (GMT_BUILD_GMTMEX)

and add GMT_GMTMEX_SRCS to the list of things lin libgmt. This builds a libgmt with the right glue and otool -L shows links to my own matlab mx and mex libraries. Futhermore, this seems to be the end product! If I add a link gmtmex.mexmaci64 -> libgmt.6.dylib then matlab runs the gmt/mex toolbox, because all matlab does is (1) check for correct extension, (2) look for a function called mexFunction and launch it in matlab.

Instead of installing a program, I would like to add a symbolic link gmtmex.mexmaci64 -> libgmt.6.dylib in cmake. Is there a special command for that?

@seisman
Copy link
Member

seisman commented Sep 25, 2020

Try if this works:

file (CREATE_LINK libgmt.6.dylib gmtmex.mexmaci64 SYMBOLIC)

@PaulWessel
Copy link
Member Author

It did create but in wrong dir, etc. This is the top of the build dir:

(base) pwessel@macnut:~/GMTdev/gmt-dev/dbuild-> ls -lg gmtmex.mexmaci64
lrwx--x--x 1 wessel 14 Sep 24 15:42 gmtmex.mexmaci64 -> libgmt.6.dylib

Maybe more like

file (CREATE_LINK${GMT_LIBDIR}/${LIB_PREFIX}gmt.${GMT_LIB_SOVERSION}.${CMAKE_SHARED_LIBRARY_SUFFIX} ${GMT_LIBDIR}//gmtmex.${MEX_EXT} SYMBOLIC)

Is there any shorter expressions for path to library instead of the above? Will try.

@PaulWessel
Copy link
Member Author

Timing issues? Changing the dir seems like it is trying to create link before lib is ready:

CMake Error at src/CMakeLists.txt:570 (file):
file failed to create symbolic link 'lib/gmtmex.mexmaci64': no such file or
directory

@PaulWessel
Copy link
Member Author

We have other symbolic links being made by cmake. hack based on this instead?

# symlink to gmt-wrapper in bindir and libdir:
if (UNIX AND GMT_INSTALL_NAME_SUFFIX)
	get_target_property(_gmt_wrapper_name gmt OUTPUT_NAME)
	install (CODE "
	execute_process (
		COMMAND ${CMAKE_COMMAND} -E create_symlink
		\"${_gmt_wrapper_name}\" \"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${GMT_BINDIR}/gmt\")
	")
endif (UNIX AND GMT_INSTALL_NAME_SUFFIX)

@seisman
Copy link
Member

seisman commented Sep 25, 2020

symlink to gmt-wrapper in bindir and libdir:

if (UNIX AND GMT_INSTALL_NAME_SUFFIX)
get_target_property(_gmt_wrapper_name gmt OUTPUT_NAME)
install (CODE "
execute_process (
COMMAND ${CMAKE_COMMAND} -E create_symlink
"${_gmt_wrapper_name}" "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/${GMT_BINDIR}/gmt")
")
endif (UNIX AND GMT_INSTALL_NAME_SUFFIX)

Yes, should have an install command like this one.

@PaulWessel
Copy link
Member Author

Hi @seisman, were did we leave your experiments on gmtmex etc? I want to return to this after the PR on basemap placements etc. @joa-quim and I have realized tehre is nothing in the gmtmex dir that is independent of Matlab libs and includes so all we plan to do is just build the gmtmex.extension shared lib and in that sense gmtmex is not a supplement but a directory with optional code for matlab.

@seisman
Copy link
Member

seisman commented Oct 1, 2020

were did we leave your experiments on gmtmex etc?

What do you mean? What experiments? Experiments on the macOS bundle #1930 (comment)?

@PaulWessel
Copy link
Member Author

Maybe I am dreaming (well, since I cannot find the issue and there is no PR apart from my WIP), but I could swear you tested something that involved gmtmex and since I was in the middle on my PR I stopped to see how that went - I am sure motivated by the bundle failyre in PyGMT.

@joa-quim
Copy link
Member

joa-quim commented Oct 2, 2020

Yes, that relates with the gmtmex on Mac because it would greatly make it possible to distribute gmtmex in the bundle.

@seisman
Copy link
Member

seisman commented Oct 2, 2020

The only related issue I can find is #1930.

@PaulWessel
Copy link
Member Author

OK, maybe I extrapolated that too much. Were you successful in building a bundle that worked with pyGMT?

@seisman
Copy link
Member

seisman commented Oct 3, 2020

I can't build a working bundle from the master branch recently. The macOS bundle is successfully built but when running gmt, it says "Illegal instruction".

No special code needed in gmt_api.c - the KEYS work.  The initial problem was lack of output file name.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants