Comments (7)
Particularly interested in @seisman's thought on this to minimize maintenance.
from custom-supplements.
When I tried to build the custom shared library today (mkdir build; cd build; cmake ..) I got errors about not finding stdio.h, so something very fundamental is missing.
This is what I just got:
-- Performing Test memchrExists
-- Performing Test memchrExists - Failed
-- ANSI C header files - not found
-- Using CFLAGS = ' -O3 -DNDEBUG'
CMake Warning (dev) at CMakeLists.txt:65 (get_property):
Policy CMP0026 is not set: Disallow use of the LOCATION target property.
Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
The LOCATION property should not be read from target "customlib". Use the
target name directly with add_custom_command, or use the generator
expression $<TARGET_FILE>, as appropriate.
This warning is for project developers. Use -Wno-dev to suppress it.
* Options:
* GMT library : /Users/seisman/local/GMT/lib/libgmt.dylib
* GMT include dir : /Users/seisman/local/GMT/include/gmt
*
* Locations:
* Custom name : custom
* CUSTOM library : custom.so
* Installing CUSTOM in : /usr/local
* CUSTOM_SHARE_PATH : /usr/local/
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/seisman/Gits/gmt/custom-supplements/build
$ make
Scanning dependencies of target customlib
[ 16%] Building C object src/CMakeFiles/customlib.dir/gmt_custom_module.c.o
/Users/seisman/Gits/gmt/custom-supplements/src/gmt_custom_module.c:51:41: error: expected expression
{"gmtaverage", "gmtaverage", "custom", , "Block average (x,y,z) data tables by mean, median, or mode estimation"},
^
/Users/seisman/Gits/gmt/custom-supplements/src/gmt_custom_module.c:52:41: error: expected expression
{"gmtmercmap", "gmtmercmap", "custom", , },
^
/Users/seisman/Gits/gmt/custom-supplements/src/gmt_custom_module.c:53:39: error: expected expression
{"gmtparser", "gmtparser", "custom", , },
^
/Users/seisman/Gits/gmt/custom-supplements/src/gmt_custom_module.c:54:41: error: expected expression
{"grdfourier", "grdfourier", "custom", , },
^
4 errors generated.
make[2]: *** [src/CMakeFiles/customlib.dir/gmt_custom_module.c.o] Error 1
make[1]: *** [src/CMakeFiles/customlib.dir/all] Error 2
make: *** [all] Error 2
from custom-supplements.
Thanks I will fix that in a bit - side-tracked by Chair business...
from custom-supplements.
Separately from that repo, I think it would be great if we could extend the support we have in the main GMT CMake setup where we have EXTRA_BUILD_DIRS and EXTRA_MODULES_SUPPL. What I have in mind is the ability for developers to add a separate supplement dir to this mix, but have it build as a separate *.so file and not become part of supplements.so. This would simplify the whole build for such developers since they can simply rely on the main GMT cmake setup. How could we do this? Allow a symbolic link called custom to be placed in src (and ignored by .gitignore) and let our Cmake determine if there is such a thing then build custom.so?
I think it's a good idea for developers who want to write GMT plugins for their own use. We can add more cmake variables, e.g. BUILD_CUSTOM_LIBS, CUSTOM_LIB_NAME, CUSTOM_DIRS, to configure how custom plugins are found.
from custom-supplements.
I am thinking that some of our supplements (e.g., spotter) may be too specialized and only has one maintainer (me) and that it will not last very long into the future. Maybe that one and maybe all of them should be separate shared libs and supplements.so goes away,
from custom-supplements.
I'm OK with that, as long as it's transparent to end-users.
from custom-supplements.
I have a feeling that whatever is built on this repo will always be out of date with the main repo. GMT development moves really fast and breaks things like this quite often. It might be worth moving things to the main repo to try to avoid that. Or at least have CI build nightly on this to send notifications when things break against master.
As part of making GMT more sustainable, I really like the idea of making supplements truly supplemental. Having a GMT federation instead of putting the burden on the current core is a good idea. And it encourages new people to take ownership. But that requires making people feel like this is their project too, not just ours (which is kind of the feeling I get from the forum comments).
from custom-supplements.
Related Issues (1)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from custom-supplements.