-
Notifications
You must be signed in to change notification settings - Fork 359
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
base: master
Are you sure you want to change the base?
Conversation
… gmtmex First goal is to have this no break regular GMT when GMT_BUILD_GMTMEX is not set.
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.
It seems to build the two object files under dbuild/src:
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
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? |
src/gmtmex/CMakeLists.txt
Outdated
set (SUPPL_PROGS_SRCS gmtmex.c gmtmex_parser.c) | ||
set (SUPPL_HEADERS gmtmex.h) | ||
set (SUPPL_LIB_SRCS ${SUPPL_PROGS_SRCS}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may work:
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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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:
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 |
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
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? |
Try if this works:
|
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 Maybe more like
Is there any shorter expressions for path to library instead of the above? Will try. |
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): |
We have other symbolic links being made by cmake. hack based on this instead?
|
Yes, should have an |
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. |
What do you mean? What experiments? Experiments on the macOS bundle #1930 (comment)? |
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. |
Yes, that relates with the gmtmex on Mac because it would greatly make it possible to distribute gmtmex in the bundle. |
The only related issue I can find is #1930. |
OK, maybe I extrapolated that too much. Were you successful in building a bundle that worked with pyGMT? |
I can't build a working bundle from the master branch recently. The macOS bundle is successfully built but when running |
No special code needed in gmt_api.c - the KEYS work. The initial problem was lack of output file name.
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.