Closed Bug 1604026 Opened 5 years ago Closed 5 years ago

Complete rebuilds caused even after minute changes: config.status is out of date ...

Categories

(Thunderbird :: Build Config, defect)

Product:
Thunderbird
Component:
Build Config
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jorgk-bmo, Unassigned)

Details

$ mach build
c:/mozilla-source/comm-central/obj-x86_64-pc-mingw32/config.status is out of date with respect to c:/mozilla-source/comm-central/obj-x86_64-pc-mingw32/_virtualenvs/init/lib/site-packages/mozfile/init.py

And then the whole thing builds again and I have to wait 30+ minutes :-(

Flags: needinfo?(rob)
Flags: needinfo?(geoff)

Indeed. As a workaround you can remove this line.

Flags: needinfo?(geoff)

So why isn't https://searchfox.org/comm-central/rev/023f60c129f6d7eceed681e41916a24e8dd225f7/mail/test/mozmill/Makefile.in#26 removed for good then? Is there another solution planned?

So that we still have Mozmill.

Sorry, I don't get it. We've run MozMill for the last decade or so and it never caused issues with rebuilding, at least not that I noticed. So something has changed, maybe in the "copy MozMill to Mochitest" action. So the solution should be to fix what got broking without ripping out MozMill just yet.

I also don' understand the code/comment:

ifndef MOZ_AUTOMATION
# We don't run mozmill tests as part of the build in automation, so skip
# creating a virtualenv for them.
libs:: mozmill-virtualenv
endif

We don't run mozmill tests? Last I checked, we did. Or not part of the build? I'm very confused, but I can say that this stuff caused me three entire unwanted recompiles for changing a few lines of C++ or JS code :-(

For me something changed around last Tuesday. I think at the same time clang needed to be updated to build. (Maybe unrelated.)
It's not a full recompile for me, but it went from like 20s to 3 minutes for a c++ change recompile.

I get a full recompile of 30+ minutes for any small change. It starts with probing the config like after a clobber :-(
I do touch c:/mozilla-source/comm-central/obj-x86_64-pc-mingw32/config.status to mitigate that.

Whatever it was, after the enforced cargo install cbindgen --force today I'm back to the normal build times.

Still not better on Windows.

Well, maybe I have to repeat the NI :-( - Geoff, see comment #4. Richard, does comment #6 help, of course adapted to your environment? Since I'm on PTO, I'm only compiling occasionally, so it doesn't really matter much.

Flags: needinfo?(geoff)

After today's enforced rust update, I get the 3 min compile again, instead of 30s like yesterday.

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #9)

Richard, does comment #6 help, of course adapted to your environment?

It helps to build in 3 minutes instead of around 25.

Now with mozmill gone, do you still see this? I don't anymore.

This was caused by the Mozmill installation process (in combination with build system changes), therefore it doesn't happen any more.

I suspect it actually stopped before we removed Mozmill, but does it really matter?

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(rob)
Flags: needinfo?(geoff)
Resolution: --- → WORKSFORME

Now that I noticed this bug, here is my discovery.
I am using Debian GNU/Linux amd64.

I used to have something like the following in the build log and saw the complete configure steps took place AGAIN after a configure had previously done and a minor edit was done in C-C tree which was annoying.

 /NEW-SSD/moz-obj-dir/objdir-tb3/config.status is out of date with respect to /NEW-SSD/NREF-COMM-CENTRAL/mozilla/build/moz.configure/warnings.configure

I believe I noticed that in December or late November. I think I posted about this in one of the mailing lists.

Today, though, in my case, after M-C, C-C refresh (together), the above line is certainly seen and configure takes place (as it should), but
after a minor edit, the above no longer appears and only the compilation of the modified file(s) and link of the thunderbird happens now.

This is under linux and maybe Windows might have an issue with one of the build/make tools?

(In reply to Jorg K (GMT+1) (PTO to 26th Jan 2020, sporadically reading bugmail) from comment #6)

I get a full recompile of 30+ minutes for any small change. It starts with probing the config like after a clobber :-(
I do touch c:/mozilla-source/comm-central/obj-x86_64-pc-mingw32/config.status to mitigate that.

I thought of that, too when I noticed the issue.

I think there is clearly a timing-dependent issue when we use multi-threaded build.
I think the logic to serialize the creation of config.status and warnings.configure probably is broken when we use multi-thread and linux and windows have enough timing difference of process creation/execution.

You need to log in before you can comment on or make changes to this bug.