On Fri, 4 Dec 2020 at 22:20, Karl Berry wrote:
> You sent the proposed change in the bug report to Bruno, so I committed
> it in your name.
>
Sorry, I didn't mean to say I had nothing to do with the contents of the
patch, just that I didn't have anything to do with installing it. (And I
wasn't a
You sent the proposed change in the bug report to Bruno, so I committed
it in your name.
changed from "C file newer than Vala file" to "C file not older than
Vala file".
Yeah. Sorry that I wrote the log words too quickly.
If this change is documented elsewhere it might be worth notin
I just noticed while updating to look at something else that a version of
my patch seems to have been applied, but with a misleading commit message.
It has my name on it, commit 7581ec208. But I don't think I had anything to
do with that commit!
The commit log says: "reverse -newer test". But it
On Sat, 21 Nov 2020 at 22:01, Karl Berry wrote:
>
> By the way, I don't think that find command (or the cp -p for that
> matter) is excessively portable. But I guess we don't much care about
> crufty systems for vala support. --thanks, karl.
>
They are both using only POSIX-2008 features; these
Thanks Reuben.
line 5737 of automake.in would become:
. "\t\@if test ! -f \$@ && test \$(srcdir) != \$(builddir) &&
test -n \"\$\$(find -L \$(srcdir)/$vala_file) -prune \! -newer
\$(srcdir)/$c_file\"; then cp -p \$(srcdir)/$c_file $built_c_file; fi\n"
Bruno, can you p
[CCing the bug, though this email wasn't addressed to it; looks like it
should have been, though!]
Indeed, the generated C file shouldn't be rebuilt; the existing distributed
C source file should be used.
I tried the test with v1.16.3 and it passed for me. Looking at the logs, I
found this line i
