Re: What's cooking in git.git (Aug 2020, #01; Mon, 3)
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Aug 12, 2020, 13:35 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2008121516560.50@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20200804192053.GA1400936@coredump.intra.peff.net>
Hi Peff,
On Tue, 4 Aug 2020, Jeff King wrote:
Show 24 quoted lines
> On Tue, Aug 04, 2020 at 11:58:43AM -0700, Junio C Hamano wrote: > > > > I ran into issues with this, as I have several in-progress topics (not > > > yet sent to the list) that touch our Makefile, and they needed updates > > > to the cmake file (because it reproduces a lot of the lists and logic > > > from the Makefile). > > > > > > The original philosophy behind putting it in contrib is that most people > > > wouldn't have to care, and folks interested in cmake would be > > > responsible for keeping it up to date. But the top patch makes it hard > > > to ignore, because the vs-build CI job will fail. > > > > > > I'm not sure of the right path forward. I was definitely unenthused to > > > be dealing with cmake, and the problem came up as soon as the series hit > > > next. > > > > My hope is that if we let vs-build broken long enough, those who > > want to see cmake to graduate would fix it. We can always threaten > > the topic to be discarded out of 'next' after the next release if it > > hasn't been fixed ;-) > > That was my philosophy, too, but it's annoying in the meantime as I get > a notification for "your build is broken" every time I run CI. So it > becomes a game of chicken over who gets annoyed first. ;)
I am a bit sad to read all this, as I thought that we had reached consensus that the `Makefile` _is_ the source of truth.
But then, most of the source files that need to be compiled _are_ parsed from the Makefile.
So I wonder what problems you ran into; Maybe we can come up with a strategy how to preempt future instances of the same nature?
Ciao, Dscho