Jeff King writes:
> On Wed, Mar 06, 2019 at 12:23:20AM +, Ramsay Jones wrote:
>
>> > Yeah, that's what I was hinting at earlier in the thread. Here it is
>> > sketched out to an actual working patch. The sub-make bits could
>> > actually be a shell script instead of a Makefile; the only point
On Wed, Mar 06, 2019 at 12:23:20AM +, Ramsay Jones wrote:
> > Yeah, that's what I was hinting at earlier in the thread. Here it is
> > sketched out to an actual working patch. The sub-make bits could
> > actually be a shell script instead of a Makefile; the only point in
> > using make is to u
On 05/03/2019 23:07, Jeff King wrote:
> On Tue, Mar 05, 2019 at 02:50:11PM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> This makes sense to me, though as you noted elsewhere, it doesn't fix
>>> the gcrypt problem, since that file unconditionally wants to look at the
>>> system gc
On Tue, Mar 05, 2019 at 02:50:11PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > This makes sense to me, though as you noted elsewhere, it doesn't fix
> > the gcrypt problem, since that file unconditionally wants to look at the
> > system gcrypt.h (and we control at the Makefile level w
Johannes Schindelin writes:
>> After a normal build, with dynamic dependency checking on, we would
>> have sufficient information to figure it out. Would that help?
>
> Yes, *if* the dynamic dependency checking is in effect (read: if we are
> compiling with GCC).
>
> However, I think that one of
Hi Junio,
On Tue, 5 Mar 2019, Junio C Hamano wrote:
> Jeff King writes:
>
> > This makes sense to me, though as you noted elsewhere, it doesn't fix
> > the gcrypt problem, since that file unconditionally wants to look at the
> > system gcrypt.h (and we control at the Makefile level whether we
>
Jeff King writes:
> This makes sense to me, though as you noted elsewhere, it doesn't fix
> the gcrypt problem, since that file unconditionally wants to look at the
> system gcrypt.h (and we control at the Makefile level whether we
> actually look at sha256/gcrypt.h).
Hmm, is that because the he
On Mon, Mar 04, 2019 at 12:08:41PM +0100, Johannes Schindelin wrote:
> -- snipsnap --
> From c13d9985284d4b452db0d95b6949e02c533db634 Mon Sep 17 00:00:00 2001
> From: Johannes Schindelin
> Date: Sat, 23 Feb 2019 20:38:40 +0100
> Subject: [PATCH] hdr-check: make it work on Windows
>
> On Windows,
On Mon, Mar 04, 2019 at 01:38:13PM +0100, Johannes Schindelin wrote:
> > So, tl;dr: soon, I will be submitting a patch to remove the
> > 'hdr-check' target completely, for now anyway.
>
> You mentioned later that you might be the only person using that target,
> and if that were so, I would agree
On 04/03/2019 12:38, Johannes Schindelin wrote:
>> So, tl;dr: soon, I will be submitting a patch to remove the
>> 'hdr-check' target completely, for now anyway.
>
> You mentioned later that you might be the only person using that target,
> and if that were so, I would agree.
It is obviously d
Hi Ramsay,
On Sun, 3 Mar 2019, Ramsay Jones wrote:
> On 03/03/2019 17:19, Jeff King wrote:
> > On Sat, Mar 02, 2019 at 09:05:24PM +0100, Johannes Schindelin wrote:
> >
> >>> That seems reasonable (regardless of whether it is in a script or in the
> >>> Makefile). Another option is to use -maxdep
Hi Peff,
On Sun, 3 Mar 2019, Jeff King wrote:
> By the way, "make hdr-check" already fails for me on master, as I do not
> have libgcrypt installed, and it unconditionally checks sha256/gcrypt.h.
Oh? I thought it'd fail only on Windows, so I have not submitted
https://github.com/dscho/git/commit
On 03/03/2019 17:19, Jeff King wrote:
> On Sat, Mar 02, 2019 at 09:05:24PM +0100, Johannes Schindelin wrote:
>
>>> That seems reasonable (regardless of whether it is in a script or in the
>>> Makefile). Another option is to use -maxdepth, but that involves
>>> guessing how deep people might act
On Sat, Mar 02, 2019 at 09:05:24PM +0100, Johannes Schindelin wrote:
> > That seems reasonable (regardless of whether it is in a script or in the
> > Makefile). Another option is to use -maxdepth, but that involves
> > guessing how deep people might actually put header files.
>
> It would also fa
On Sat, Mar 02, 2019 at 08:57:57PM +0100, Johannes Schindelin wrote:
> Hi Peff,
>
> On Fri, 1 Mar 2019, Jeff King wrote:
>
> > On Fri, Mar 01, 2019 at 04:36:19PM -0500, Jeff King wrote:
> >
> > > > This has one notable consequence: we no longer include
> > > > `command-list.h` in `LIB_H`, as it
On Sat, Mar 02, 2019 at 08:54:55PM +0100, Johannes Schindelin wrote:
> On Fri, 1 Mar 2019, Jeff King wrote:
>
> > On Fri, Mar 01, 2019 at 04:54:15PM -0500, Jeff King wrote:
> >
> > > The one thing we do lose, though, is make's parallelization. It would
> > > probably be possible to actually shov
Hi Peff,
On Fri, 1 Mar 2019, Jeff King wrote:
> On Fri, Mar 01, 2019 at 11:57:46AM -0800, Johannes Schindelin via
> GitGitGadget wrote:
>
> > In d85b0dff72 (Makefile: use `find` to determine static header
> > dependencies, 2014-08-25), we switched from a static list of header
> > files to a dyn
Hi Peff,
On Fri, 1 Mar 2019, Jeff King wrote:
> On Fri, Mar 01, 2019 at 04:36:19PM -0500, Jeff King wrote:
>
> > > This has one notable consequence: we no longer include
> > > `command-list.h` in `LIB_H`, as it is a generated file, not a
> > > tracked one.
> >
> > We should be able to add back
Hi Peff,
On Fri, 1 Mar 2019, Jeff King wrote:
> On Fri, Mar 01, 2019 at 04:54:15PM -0500, Jeff King wrote:
>
> > The one thing we do lose, though, is make's parallelization. It would
> > probably be possible to actually shove this into a sub-make which
> > defined the hdr-check rules, but I don'
On Fri, Mar 01, 2019 at 04:54:15PM -0500, Jeff King wrote:
> The one thing we do lose, though, is make's parallelization. It would
> probably be possible to actually shove this into a sub-make which
> defined the hdr-check rules, but I don't know how complicated that would
> become.
This seems to
On Fri, Mar 01, 2019 at 04:36:19PM -0500, Jeff King wrote:
> > However, as of ebb7baf02f (Makefile: add a hdr-check target,
> > 2018-09-19), $(LIB_H) is part of a global rule and therefore must be
> > expanded. Meaning: this `find` command has to be run upon every
> > `make` invocation. In the pre
On Fri, Mar 01, 2019 at 11:57:46AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> In d85b0dff72 (Makefile: use `find` to determine static header
> dependencies, 2014-08-25), we switched from a static list of header
> files to a dynamically-generated one, asking `find` to enumerate them.
>
22 matches
Mail list logo
