bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]