1017775 - Thunderbird is failing in configure: No such file or directory: '.../build/mozilla/objdir-tb' since Bug 832112

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Philip Chee]

Thunderbird is failing in configure:

OSError: [Errno 2] No such file or directory: '/builds/slave/tb-c-cen-lx-000000000000000000/build/mozilla/objdir-tb'
configure: error: /builds/slave/tb-c-cen-lx-000000000000000000/build/mozilla/configure failed for mozilla
*** Fix above errors and then restart with               "make -f client.mk build"
make[2]: *** [configure] Error 1
make[2]: Leaving directory `/builds/slave/tb-c-cen-lx-000000000000000000/build'
make[1]: *** [objdir-tb/Makefile] Error 2
make[1]: Leaving directory `/builds/slave/tb-c-cen-lx-000000000000000000/build'
make: *** [build] Error 2

Comment 1

[Michael Shal [:mshal]]

I'm not sure what the correct fix here is. It seems like the code in m-c/python/mozbuild/mozbuild/base.py might need to be fiddled with to account for this scenario. Specifically, we're failing because the MOZ_OBJDIR is a relative path, which is assumed to be relative to topsrcdir, which is c-c/mozilla in this case. So c-c thinks the objdir is c-c/obj-tb, and m-c thinks it should be c-c/mozilla/obj-tb. Of course this only broke recently because mach/mozbuild code now actually respects the MOZ_OBJDIR environment variable.

gps, any idea of what we should change here?

One other solution would be to set MOZ_OBJDIR to a full path in the c-c automation, but I think that's more of a work-around.

Comment 2

[Joshua Cranmer [:jcranmer]]

I did a patch that changed MOZ_OBJDIR in the c-c configure for the m-c configure. It failed for universal builds, though.

Comment 3

[Mike Hommey [:glandium]]

Can we have cc-rework already?

Comment 4

[Joshua Cranmer [:jcranmer]]

(In reply to Mike Hommey [:glandium] from comment #3)
> Can we have cc-rework already?

Realistically:
1. cc-rework with the merge is basically blocked on factors outside of my control.
2. cc-rework without the merge would require:
2a. rewriting patches to account for different directory layout (~1 day of work)
2b. figuring out how to get mozilla-central to pull comm-central (~1 week + review turnarounds)
2c. figuring out automation stories for new layout and new try-comm-central (??? months, knowing how overburdened releng is right now?)

The story for the merge was left at "let's wait until we start ripping out our buildbot infrastructure" (Q3-ish). Unfortunately, I never got a decisive question to the answer "would the merge happen at this time," although it appears I do have support from releng for a "yes" answer (it seems to me that no one really wants to discuss it).

(In reply to Joshua Cranmer [:jcranmer] from comment #2)
> I did a patch that changed MOZ_OBJDIR in the c-c configure for the m-c
> configure. It failed for universal builds, though.

This ends up failing later on in one of our generated files generation. :-(

Comment 5

[Joshua Cranmer [:jcranmer]]

Attachment: Stop passing MOZ_OBJDIR to mozilla's build system

I'll take the first one who can review this patch :-)

This is nothing less than a gross hack, I'll admit. MOZ_OBJDIR is effectively unnecessary outside of client.mk, so I forced client.mk to basically stop passing it to configure and the build system. Since it's still in the environment when we want to run make check, I made the c-c makefile kill the export there too.

Try run: <https://tbpl.mozilla.org/?tree=Thunderbird-Try&onlyunstarred=1&rev=4271313d1666> (there's also new check-sync-dirs and xpcshell bustage. Yay.)

Comment 6

[Mike Hommey [:glandium]]

Comment on attachment 8432183 [details] [diff] [review]
Stop passing MOZ_OBJDIR to mozilla's build system

Review of attachment 8432183 [details] [diff] [review]:
-----------------------------------------------------------------

::: client.mk
@@ +131,5 @@
>  endif
>  
> +# Don't export MOZ_OBJDIR outside of this file. It just causes problems thanks
> +# to the weird build structure of comm-central.
> +MOZ_MAKE_FLAGS += MOZ_OBJDIR=

You could try to unexport MOZ_OBJDIR instead. You might not need more than that.

Comment 7

[Joshua Cranmer [:jcranmer]]

(In reply to Mike Hommey [:glandium] from comment #6)
> Comment on attachment 8432183 [details] [diff] [review]
> Stop passing MOZ_OBJDIR to mozilla's build system
> 
> Review of attachment 8432183 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: client.mk
> @@ +131,5 @@
> >  endif
> >  
> > +# Don't export MOZ_OBJDIR outside of this file. It just causes problems thanks
> > +# to the weird build structure of comm-central.
> > +MOZ_MAKE_FLAGS += MOZ_OBJDIR=
> 
> You could try to unexport MOZ_OBJDIR instead. You might not need more than
> that.

I tried that first. It didn't work--I think the command-line flags overrode the unexport. (The automation runs with:
MOZ_OBJDIR=objdir-tb make -f client.mk build MOZ_OBJDIR=objdir-tb

Comment 8

[Mike Hommey [:glandium]]

(In reply to Joshua Cranmer [:jcranmer] from comment #7)
> I tried that first. It didn't work--I think the command-line flags overrode
> the unexport. (The automation runs with:
> MOZ_OBJDIR=objdir-tb make -f client.mk build MOZ_OBJDIR=objdir-tb

Sounds to me you should just change that instead of working around it.

Comment 9

[Joshua Cranmer [:jcranmer]]

Automation changes take much longer to fix than code changes. And after poking with Make's variable rules at this point, I've given up on trying to make any sense of them. I'll take what I can get and what I know works.

Comment 10

[Mike Hommey [:glandium]]

(In reply to Joshua Cranmer [:jcranmer] from comment #7)
> > You could try to unexport MOZ_OBJDIR instead. You might not need more than
> > that.
> 
> I tried that first. It didn't work

Actually, I see no reason why that would fail if you unexport it in c-c's client.mk. Please show a log of that.

That said, I'd rather backout bug 832112 for now than adding more hacks.

Comment 11

[Joshua Cranmer [:jcranmer]]

Attachment: Only using unexport MOZ_OBJDIR

This is the log failure when I only use unexport MOZ_OBJDIR.

I'm not incompetent: I did read the make manual, try this first, and then spend several hours trying to figure out why MOZ_OBJDIR was *still* getting passed through to later layers.

The solution I came up with in the bug isn't exactly the only solution I came up with, but it was the cleanest I could find that could pass the try builds.

Comment 12

[Mike Hommey [:glandium]]

At least you could have mentioned what was breaking. Now that I see what's going on, I'll just insist on backing out bug 832112.

Comment 13

[Michael Shal [:mshal]]

(In reply to Mike Hommey [:glandium] from comment #12)
> At least you could have mentioned what was breaking. Now that I see what's
> going on, I'll just insist on backing out bug 832112.

Do you have another suggestion for how to handle bug 832112 then? Without it we can't easily replace 'make -f client.mk' with './mach build' in automation, since 'MOZ_OBJDIR=foo ./mach build' is broken.

Comment 14

[Mike Hommey [:glandium]]

(In reply to Michael Shal [:mshal] from comment #13)
> Do you have another suggestion for how to handle bug 832112 then? Without it
> we can't easily replace 'make -f client.mk' with './mach build' in
> automation, since 'MOZ_OBJDIR=foo ./mach build' is broken.

There are several possibilities, but I'd rather unblock c-c while I think about them.

Comment 15

[Joshua Cranmer [:jcranmer]]

Fixed by backing out bug 832112.