993170 - Remove generated configure file from repository

Status: RESOLVED WONTFIX

(NSPR :: NSPR, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Should we remove configure from the repository? Since it is a generated file, it is causing issues with file versioning and control, Mercurial in particular.

http://hg.mozilla.org/mozilla-central/file/default/nsprpub/configure

FWIW, it is not in js/src, and it is present in .hgignore.

I guess we could remove it and add corresponding entries to nsprpub in .hgignore for:

# SpiderMonkey configury
^js/src/configure$
^js/src/autom4te.cache$

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: patch v0

Taking an early stab at this.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

$ hg st
M nsprpub\configure
? nsprpub\autom4te.cache\output.0
? nsprpub\autom4te.cache\requests
? nsprpub\autom4te.cache\traces.0

These is an example of a problem I hit when trying to bisect, or when applying a patch via mq then qpop'ing it later.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: patch v0.1

Take 2, rebased to apply on top of changeset 488caa16c617 on mozilla-inbound tip.

Comment 4

[Wan-Teh Chang]

Hi Gary,

Thank you for the patch. The NSPR upstream has the generated
configure file so that people can run configure directly.
As for the nsprpub directory in the Mozilla source tree, I
would prefer that it is an exact copy of the NSPR upstream.
But if you really want to remove nsprpub/configure in the
Mozilla source tree, you need to modify the script we use
to import an NSPR tag into the Mozilla source tree. It is
step 2 in this page:

https://developer.mozilla.org/en-US/docs/Updating_NSPR_or_NSS_in_mozilla-central

Also note that the latest nsprpub/configure.in requires
autoconf 2.6x.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

In this case, does it make sense to only add nsprpub/configure to .hgignore?

(Yes, I know about the newer autoconf 2.6x for newer versions, and autoconf 2.13 for older ones)

Comment 6

[Mike Hommey [:glandium]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2)
> $ hg st
> M nsprpub\configure
> ? nsprpub\autom4te.cache\output.0
> ? nsprpub\autom4te.cache\requests
> ? nsprpub\autom4te.cache\traces.0
> 
> These is an example of a problem I hit when trying to bisect, or when
> applying a patch via mq then qpop'ing it later.

That means autoconf is being run despite configure being there and up-to-date. /That/ is the real problem (combined with everyone having different versions of autoconf which lead to configure being different for everyone)

Comment 7

[Wan-Teh Chang]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #5)
> In this case, does it make sense to only add nsprpub/configure to .hgignore?

.hgignore is for files not tracked by hg, right? nsprpub/configure
is under hg control.

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 8402990 [details] [diff] [review]
patch v0.1

It sounds like this isn't a good way forward then. I'll see if I can figure something out on my side - in the meantime let's obsolete this patch.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Seems like the generated configure file also works on Windows, and autoconf is not needed to be run prior, so I guess this issue is a WONTFIX.