[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] multiple --local-dir options
From: |
Pavel Raiskup |
Subject: |
Re: [PATCH] multiple --local-dir options |
Date: |
Mon, 23 Nov 2015 13:01:41 +0100 |
User-agent: |
KMail/4.14.10 (Linux/4.2.6-300.fc23.x86_64; KDE/4.14.14; x86_64; ; ) |
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.
Pavel