On 07/12/15 10:46, Pádraig Brady wrote: > On 23/11/15 12:01, Pavel Raiskup wrote: >> On Monday 23 of November 2015 11:31:15 Pádraig Brady wrote: >>> On 23/11/15 08:30, Pavel Raiskup wrote: >>>> Hello maintainers, >>>> >>>> I planned to reuse some of my local gnulib modules in multiple projects. >>>> >>>> Because the modules are not yet ready to be proposed against gnulib >>>> master, I need to keep track them "downstream". Its painful however to >>>> C&P the local module contents all the time from project_A to project_B. >>>> >>>> The attached patch would help a lot: >>>> >>>> $ cd project_A >>>> $ git submodule add project_B /path/to_project_B >>>> $ gnulib --local-dir project_B/gl --local-dir gl ... >>>> >>>> Thanks for considering, >>> >>> While a nicely written and documented change, >>> it's quite invasive. >> >> I agree. I was too quite surprised and tempted to give up. But to me >> this is really worth applying.. >> >>> I have the niggling feeling that if multiple projects >>> need something, then it should just be pushed upstream? >> >> At the end of the day, yes, but... >> >>> What are the conditions that would warrant this? Licensing? >> >> .. In my my case it is lack of willingness and man-power to write the code >> portably and properly enough **NOW**. To be able to mark the code as >> "gnulib-ready" and wait for upstream inclusion (not everybody is able to >> commit to gnulib). Gnulib is about stability -- and the newly developed >> API can grow somewhere else (and bother different people than gnulib >> maintainers while stabilizing). >> I can imagine however that licensing could be issue too. > > I'm still concerned that merging this will increase complexity > and facilitate tech debt by supporting out of tree modules > being shared across multiple projects. > > Though it's well written and refactored. > I'm 60:40 for merging and will do so soon unless others object.
Pushed. thanks! Pádraig.
