Conversation
| $(EDIT_PREPROCESSED): $(SRC) | ||
| # Instead of making the prepare-robot-plugins a dependency, we just call the goal | ||
| # to update the plugins when we need it | ||
| $(MAKE) prepare-robot-plugins |
There was a problem hiding this comment.
This may be preferable to putting it into the dependencies (as it is a phony goal). The symlinks are very fast, and the other plugins are only updated when the make cache is invalidated first.
| # Standard rule to create symlinks in $(TMPDIR)/plugins, so that the repository plugins | ||
| # are visible to ROBOT | ||
| prepare-robot-plugins: | ||
| for plugin in $(ROBOT_REPOSITORY_PLUGINS) ; do ln $plugin $(TMPDIR)/plugins ; done |
There was a problem hiding this comment.
This does not throw an error when the ../../plugins directory does not exist, which is good.
There was a problem hiding this comment.
But this will throw an error if there are some plugins in the ../../plugins directory but the destination directory ($(TMPDIR)/plugins) does not exist. We need a mkdir -p $(TMPDIR)/plugins before attempting to create the symlinks.
There was a problem hiding this comment.
Thank you! Just unix 101: what happens if a file is deleted in ../../plugins/*.jar after this is run? Does the seem link disappear as well?
There was a problem hiding this comment.
No. We’re creating a normal link here, not a symbolic one (or a “hard” link instead of a “soft” one) – my mistake in the previous comment for calling them “symlinks” out of habit.
If the original file in ../../plugins/ is deleted, the newly added link in $(TMPDIR)/plugins will still be there, and will still point to the same contents (technically the same inode) on the disk.
(FYI: The reason we are creating normal links instead of symbolic links is that for some reasons, from within the ODK ROBOT would not be able to correctly follow the symlinks, even if both the symlinks and the files they are pointing to are both visible from the container – I’ve tried.)
There was a problem hiding this comment.
I’ll be curious to see whether this works as expected on Windows, though. AFAIK Windows has no such concepts as links and inodes, so I don’t know how Docker on Windows will handle that…
|
|
||
| # in the custom.Makefile, users can simply attach any custom plugins they need | ||
| # as dependencies to the prepare-robot-plugins goal | ||
| prepare-robot-plugins: $(ROBOT_PLUGINS_DIRECTORY)/monarch.jar |
There was a problem hiding this comment.
renamed the goal a bit. Similar to test goal, custom Makefile extenders can simply attach the custom modules to that goal if they need to
2 participants
No description provided.