731985 - rebuild (after mozconfig change) fails

Status: RESOLVED INCOMPLETE

(MailNews Core :: Build Config, defect)

Description

[Martin Stránský [:stransky] (ni? me)]

If configure fails and user does any change in mozconfig, the next build (make -f client.mk build) fails before configure recreation and you have to delete all geberated files by hand (configure, config.log, config.cache) from root and mozilla dir.

(tested with mk_add_options MOZ_OBJDIR=@TOPSRCDIR@)

Other problem is that when configure succeeds (and compilation fails), you have to delete those files too (for configure recreation).

Comment 1

[Martin Stránský [:stransky] (ni? me)]

The error messages (configure in mozilla subdir failed, I updated the .mozconfig file and now to fails to build:

$ make -f client.mk build
Adding client.mk options from /home/komat/tmp636-tb/src/.mozconfig:
    MOZ_CO_PROJECT=mail
    MOZ_OBJDIR=$(TOPSRCDIR)
    AUTOCONF=autoconf-2.13
    BUILD_OFFICIAL=1
    MOZILLA_OFFICIAL=1
gmake -j2  -C /home/komat/tmp636-tb/src
gmake[1]: Entering directory `/home/komat/tmp636-tb/src'
gmake -j2 -C mozilla default
gmake[2]: Entering directory `/home/komat/tmp636-tb/src/mozilla'
gmake[2]: warning: -jN forced in submake: disabling jobserver mode.
STOP!  configure has changed and needs to be run in this build directory.
Please rerun configure.
To ignore this message, touch 'config.status' in the build directory,
but your build might not succeed.
gmake[2]: *** [config.status] Error 1
gmake[2]: Leaving directory `/home/komat/tmp636-tb/src/mozilla'
gmake[1]: *** [default] Error 2
gmake[1]: Leaving directory `/home/komat/tmp636-tb/src'
make: *** [build] Error 2

Comment 2

[Justin Wood (:Callek)]

(In reply to Martin Stránský from comment #1)
> The error messages (configure in mozilla subdir failed, I updated the
> .mozconfig file and now to fails to build:
> 

Yea the error message is entirely correct, you can't expect the build to succeed when stuff changes out from under it. You need to clobber if you change mozconfigs between builds.

> $ make -f client.mk build
> Adding client.mk options from /home/komat/tmp636-tb/src/.mozconfig:
>     MOZ_CO_PROJECT=mail
>     MOZ_OBJDIR=$(TOPSRCDIR)

Warning unwise/suggest-using-other OBJDIR rather than inside-source
> gmake[2]: Leaving directory `/home/komat/tmp636-tb/src/mozilla'

This is because we use multiple levels of configure... you'll need to (at a min) clear out

@topsrcdir@/ configure stuff
@topsrcdir@/mozilla/ configure stuff
@topsrcdir@/mozilla/js/src/ configure stuff

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Yes, I'm sure the message is correct. My concern is that I have to do the changes after every .mozconfig modification by hand and previous versions does not need such handlig. Is that an intended change?

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch

.mozconfig.mk check makes the trick (copied from mozilla/client.mk). I wonder who is the best reviewer for this?

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 603990 [details] [diff] [review]
patch

It looks like you're a build config peer, can you check it please?

Comment 6

[Justin Wood (:Callek)]

(In reply to Martin Stránský from comment #4)
> Created attachment 603990 [details] [diff] [review]
> patch
> 
> .mozconfig.mk check makes the trick (copied from mozilla/client.mk). I
> wonder who is the best reviewer for this?

Really this was copied? From where exactly, I don't see it in my source. (Which means if it was copied was likely backed out/removed for some reason, and I want to be sure I understand before I stamp this)

Comment 7

[Martin Stránský [:stransky] (ni? me)]

(In reply to Justin Wood (:Callek) from comment #6)
> (In reply to Martin Stránský from comment #4)
> > Created attachment 603990 [details] [diff] [review]
> > patch
> > 
> > .mozconfig.mk check makes the trick (copied from mozilla/client.mk). I
> > wonder who is the best reviewer for this?
> 
> Really this was copied? From where exactly, I don't see it in my source.
> (Which means if it was copied was likely backed out/removed for some reason,
> and I want to be sure I understand before I stamp this)

http://mxr.mozilla.org/mozilla-release/source/client.mk#297

IHm, it was backed out in trunk by Bug 715048. I wonder if it causes any regression or not.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Yes, the patch from Bug 715048 introduces the same bug to Firefox now :)

Comment 9

[Justin Wood (:Callek)]

Comment on attachment 603990 [details] [diff] [review]
patch

I'm delegating review of this to khuey, since he reviewed the patch that caused the 'regression' in m-c.

I don't quite know which situation of the two (seemingly) conflicting ones we want. But I would like to match whatever m-c wants here, so kyle can feel free to wontfix as well if he wishes.

Comment 10

[Nicholas Nethercote [inactive]]

I implemented the patch in bug 715048.  IMO, the current behaviour is preferable.  Alternating between two different builds of the same tree (e.g. debug and opt) is extremely common.  In contrast, changing a mozconfig is quite rare.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 603990 [details] [diff] [review]
patch

ted gets to make the decisions here.

Comment 12

[(not currently active) Ted Mielczarek]

Comment on attachment 603990 [details] [diff] [review]
patch

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

Historically we have required that you clobber your objdir when changing the mozconfig. I don't think we should make comm-central behave differently from mozilla-central here.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

The main problem is when configure fails (for some reason - missing packages or whatever) you have to run "touch config.status" at least which is weird. But okay, I'll try to get it fixed in mozilla-central first.

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to Martin Stránský from comment #13)
> The main problem is when configure fails (for some reason - missing packages
> or whatever) you have to run "touch config.status" at least which is weird.
> But okay, I'll try to get it fixed in mozilla-central first.

success?

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Sorry, I don't work on that now.