Re: problem with Makefile.in generation in lingomp

[Jakub Jelinek <jakub@redhat.com>]

On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
> I use 1.15.1.
> This is the link to the line I mentioned.
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29

You shouldn't be running autoreconf, just automake to regenerate
Makefile.in, and when I run it, it certainly doesn't emit that error.

Anyway, can you explain the
https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
commit?  That makes the branch quite useless.
The point is that all commits pushed to gcc trunk have to have proper
ChangeLog in the commit log to describe the actual changes in that commit.
Commits aren't allowed to be pushed there unless they satisfy the checking.
On development branches this isn't checked on commits, but if those
branches are meant to be usable for commits to trunk later, they need to
follow those rules (as I said, git gcc-verify should check it).
I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
could, you've used the same ChangeLog entry but that doesn't describe
the changes you've done in that commit, you've reverted some Makefile.am
changes (why?), removed the FSF Copyright lines (that is ok but it should
have been replaced by the Copyright The GNU Toolchain Authors. line in that
case), but the ChangeLog then would need to describe those changes.

	Jakub