Hi,
> > All this is currently implemented in GNU make syntax, so this is doable to
> > move to debhelper and not introduce some helper script. I'll try to
> > come up with something. However, I still think that the handling of the
> > plugin build configuration would be easier to maintain with a more capable
> > language than GNU make.
>
> The alternative you didn't list which I prefer is to branch out to
> interpreter-specific source packages depending on uwsgi-source and using
> dh helpers tailored for each interpreter - same as has been done already
> for php and a few others.
Now I see what you mean.
Can you confirm the list of new src packages you think about?
I can think of the following and all helper script to generate binNMUs
when uwsgi-abi changes.
src:uwsgi-libapache2-mods
building libapache2-mod-ruwsgi
building libapache2-mod-ruwsgi
src:uwsgi-plugin-python3
building uwsgi-plugin-python3
building python3-uwsgidecorators
building uwsgi-plugin-asyncio-python3
building uwsgi-plugin-gevent-python3
building uwsgi-plugin-greenlet-python3
building uwsgi-plugin-tornado-python3
src:uwsgi-plugin-ruby
building uwsgi-plugin-fiber
building uwsgi-plugin-rack
building uwsgi-plugin-rbthreads
src:uwsgi-plugin-gccgo
src:uwsgi-plugin-glusterfs
src:uwsgi-plugin-openjdk
building uwsgi-plugin-jvm
building uwsgi-plugin-jwsgi
building uwsgi-plugin-ring
building uwsgi-plugin-servlet
src:uwsgi-plugin-lua51
src:uwsgi-plugin-mono
src:uwsgi-plugin-psgi
src:uwsgi-plugin-rados
Please confirm or comment, and I'll give it a go for python. Once all done,
this should make the move the dh easy with a static list of plugins to build.
Thanks,
Alex
