[Debian GNUstep maintainers] Bug#1094879: gnustep-gui FTCBFS: configures for the build architecture during dh_auto_clean

[Yavor Doganov]

Control: tags -1 + unreproducible patch pending

That's basically exactly the same bug as agenda.app #1094007.  But the
agenda.app bug is 100% reproducible with debuild, sbuild or pbuilder
while this one is not.  The fact that agenda.app sets local.make and
config.h as prerequisites of the "before-all" target shouldn't matter
because dh_auto_clean builds the "distclean" target.  JFTR, I still
cannot reproduce this bug if I add gui.make and config.make as
prerequisites of "before-all" in gnustep-gui's GNUmakefile.postamble.

At least I understood why all of this happens -- it's because of
changes in GNU make 4.4 and 4.4.1, properly documented in NEWS.

Since your patch doesn't do any harm I'll apply it after the
gnustep-multiarch transition (there are still some sourceful uploads
of rdeps pending so I don't want to disrupt things with another
gnustep-gui upload now).

Answers to your questions below:

On Sat, 01 Feb 2025 23:14:55 +0200,
Helmut Grohne wrote:
> On Sat, Feb 01, 2025 at 07:47:18PM +0200, Yavor Doganov wrote:
> > Here is the problem but I don't understand why it happens.  From my
> > log at the end of this prerequisite check:
> > 
> > | Finished prerequisites of target file 'gui.make'.
> > |   Prerequisite 'gui.make.in' is older than target 'gui.make'.
> > |   Prerequisite 'Version' is older than target 'gui.make'.
> > |   Prerequisite 'configure' is older than target 'gui.make'.
> > 
> 
> I fear I am not seeing the cause yet. From reading the log, it very much
> seems to me that your source package would contain a gui.make. In your
> log, it says
> 
> |  Considering target file 'gui.make'.
> |   Considering target file 'gui.make.in'.
> 
> whereas in my log it says
> 
> |  Considering target file 'gui.make'.
> |   File 'gui.make' does not exist.
> 
> and this leads me to conclude that gui.make initially exists in your
> build for some reason while it does not exist in the uploaded Debian
> source package. Incidentally, what my proposed patch does is creating it
> before running make distclean.

That's definitely not the case.  It doesn't exist in the .orig.tar.gz
and in my tree.  Only configure can create it but it's not being run.
I think GNU make's messages are confusing, they are the same on
bookworm which makes me think that in your environment GNU make is
taking a different decision when parsing makefiles and deciding which
targets must be rebuilt.  Why it happens is a mystery to me.

> Your log also shows that make distclean ends up removing gui.make (as
> also happens for me).

Yes, that's a rule in GNUmakefile.postamble:

| after-distclean::
|         rm -f config.status config.log config.cache TAGS config.make gui.make

> Unfortunately, the second make distclean that also passes doc=yes is
> not run with --debug=a, so we do not see how it evaluates gui.make,
> but as it is not running configure, it probably works the same way
> as the first make distclean.

Yes, I can confirm it works the same way.  I forgot to add it, sorry.

> Would you disclose what type of filesystem your build environment uses
> for storing the build tree? In my case (and crossqa.d.n) it is tmpfs.

It's the default, ext4.

What happens if you do a native build in your environment?  Logic
dictates that it would run configure in the clean target, just like it
does for a cross build.  But this doesn't happen on the official
buildds.  (It also doesn't happen for agenda.app which was uploaded in
October while the new GNU make release was uploaded in December.)

> I'm running out of ideas on how to debug this.

Likewise.  I am very curious to find the cause because I hate leaving
questions unanswered, they are like worms eating my brain constantly.