47989 - RUN_AUTOCONF_LOCALLY ineffective

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Mike Kaply [:mkaply] (PTO until Sept 14)]

I put this as OS/2, but it is a problem on any platform that uses 
RUN_AUTOCONF_LOCALLY.

RUN_AUTOCONF_LOCALLY is basically broke. It has two main problems.

1. autoconf is not always run locally. All RUN_AUTOCONF_LOCALLY does it create a 
dependency to build configure from configure.in. The problem is that this 
dependency doesn't usually kick because a configure is automagically created by 
a chron exec and is generally later then configure.in. The only time it kicks is 
between the time a configure.in change is made and the new configure is checked 
in.

2. Because we are creating are own configure, we can get conflicts in the 
configure file on the pull. This prevents the second phase from running 
completely.

I believe there are a few ways to fix this.

1. Have RUN_AUTOCONF_LOCALLY delete the configure before and after the pull. 

2. Create a new variable that causes configure to be deleted before and after 
the pull.

Obviously these are both inefficient because autoconf is done each time.

3. Create some new dependency on configure.in such that autoconf is run locally 
whenever configure.in changes, with no dependency on the actual configure file. 
I have no idea how this would be done.

Anyway, I would be more than happy to work on this if we could find the right 
way to implement it.

Comment 1

[Mike Kaply [:mkaply] (PTO until Sept 14)]

Attachment: Here's a beginning - if the only conflict was in configure, just delete it so autoconf will run again

Comment 2

[cls]

Any luck with setting .cvsignore as leaf suggested?

Comment 3

[Mike Kaply [:mkaply] (PTO until Sept 14)]

.cvsignore does work.

I came up with another idea.

What about adding configure to .cvsignore automatically if RUN_AUTOCONF_LOCALLY 
is set?

I still think there should be something that happens to cause configure to be 
ignored if RUN_AUTOCONF_LOCALLY is set.

Comment 4

[Mike Kaply [:mkaply] (PTO until Sept 14)]

I would just like to point out that both the IRIS machines suffered from this 
problem over the weekend.

Well I would love for this bug to just go away, I still think we need an 
automated process to add configure to .cvsignore if RUN_AUTOCONF_LOCALLY is set. 
Maybe just a simple grep on configure in .cvsignore and if not, pipe it out.

Please consider it.

If not, just close this bug.

Comment 5

[Mike Kaply [:mkaply] (PTO until Sept 14)]

OK, I know I am beating a dead horse here, but because the two IRIX machines on 
ports are again sitting with conflicts in configure, I am at least moving this 
off of the OS/2 books.

Please see my previous comment for a suggested way to fix this automatically or 
just close this puppy.

Comment 6

[cls]

Just for the record, the IRIX boxes in ports are due to conflicts in
nsprpub/configure which this option doesn't even touch.  Instead of trying to do
something fancy with .cvsignore (which I believe will cause trouble over time),
what would be the side effect of always running autoconf after a pull?

Comment 7

[Mike Kaply [:mkaply] (PTO until Sept 14)]

I don't think it's a big deal that autoconf will get run every time. The problem 
is that the build dies on the checkout.

So configure would have deleted before the pull if RUN_AUTOCONF_LOCALLY is set 
to avoid the conflict in the first place.

Comment 8

[cls]

Setting milestones to Future.

Comment 9

[hacker formerly known as [e-mail]]

Attachment: Remove configures before checkout & run autoconf after checkout

Comment 10

[Mike Kaply [:mkaply] (PTO until Sept 14)]

Comment on attachment 56375 [details] [diff] [review]
Remove configures before checkout & run autoconf after checkout

r=mkaply

looks good.

Do we want to document somewhere that if you want to keep this from happening
repeatedly that you unset RUN_AUTOCONF_LOCALLY after the initial pull/build?

Comment 11

[hacker formerly known as [e-mail]]

I don't think the note is necessary.  The option isn't advertised so a developer
would have to look at client.mk to discover it in the first place.  And you
probably want this to be set always so that you get the configure.in changes
when they occur.  Right now, having it set means that configure is always
regenerated and re-run but the re-running of configure shouldn't change anything
unless you edited autoconf.mk by hand or something.

Patch checked in.  

Comment 12

[Mike Kaply [:mkaply] (PTO until Sept 14)]

This is working great for us.