Re: [PATCH] multiple --local-dir options

[Pádraig Brady]

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.