I wanted to take advantage of the features in relx that are not in the old, copied start script that has been bundled with the plugin. We could ultimately re-copy the newer relx script and apply the same cuttlefish-required changes to make it compatible, but I thought it might be nicer to make it work with a vanilla relx script.
I did this through the use of relx startup hooks and had a cuttelfish script that gets called before the application is started up. It firstly generates the configs with cuttelfish and then symlinks the resulting app config and vm_args files to the basic relx generated ones. This overrides some of the config that would have already been done in the relx script, such as NODENAME and PIPE_DIR, with new values determined by node name in the generated config.
We are currently using this feature for building Riak 3.0 and it works reliably - with the vanilla relx script we are able to use things such as the hooks and extensions. However, it is quite a way from being production ready, so I'm creating this PR so the proposed change can be scrutinised before being taken forward.
I wanted to take advantage of the features in relx that are not in the old, copied start script that has been bundled with the plugin. We could ultimately re-copy the newer relx script and apply the same cuttlefish-required changes to make it compatible, but I thought it might be nicer to make it work with a vanilla relx script.
I did this through the use of relx startup hooks and had a cuttelfish script that gets called before the application is started up. It firstly generates the configs with cuttelfish and then symlinks the resulting app config and vm_args files to the basic relx generated ones. This overrides some of the config that would have already been done in the relx script, such as NODENAME and PIPE_DIR, with new values determined by node name in the generated config.
We are currently using this feature for building Riak 3.0 and it works reliably - with the vanilla relx script we are able to use things such as the hooks and extensions. However, it is quite a way from being production ready, so I'm creating this PR so the proposed change can be scrutinised before being taken forward.