On 2016/02/07 16:10, ISHIKAWA,chiaki wrote:
On 2016/02/07 3:47, ISHIKAWA,chiaki wrote:
On 2016/02/06 18:49, Stefan Sitter wrote:
On 2016/02/04 0:19, ISHIKAWA,chiaki wrote:
Starting about 12 hours ago, I refreshed my source and got hit with
another build bustage locally.
Namely, some header files in M-C part of the tree cannot be found
during
compilation.
According to
<https://treeherder.mozilla.org/#/jobs?repo=comm-central> Linux x64,
Mac OS X and Windows compilation finished successfully on
05-Feb-2016, indicating this might be problem with your local build
only. Have you tried a clean build with clean source tree?
I missed one cruicial point.
What is the difference between the following two?
comm-central
and
try-comm-central
I noticed the build mentioned above is with comm-central.
[ Somehow, I was led to believe I should use try-comm-central for a
long time.
I could build on try-comm-central with the patch
8b2b3bdb1f7c
<https://hg.mozilla.org/try-comm-central/rev/8b2b3bdb1f7c>*ISHIKAWA,
Chiaki — fix mozilla/dom/base -I path issue.*
https://hg.mozilla.org/try-comm-central/pushloghtml?changeset=5c80e0ed4ca9
but that should not be necessary, right (?).
I have not tried the build with the patch on try-comm-central. But
maybe I should.
I meant to say I have not tried the build *WITHOUT* the patch on
try-comm-central.
I did.
And it worked for OSX and Windows(!!!), but due to the chronicle linux
build bustage (caused by infrastructure issue, I am afraid), linux
build did not succeed at all.
So I am in a situation where I can't build C-C TB under local Debian
GNU/Linux
installations (a couple of them) without a patch that fixes the
strange path issues
while I can certainly see that C-C TB try-comm-central can build
windows and OSX version without such a patch, but it does not tell
anything about
linux build due to its inability to build linux binary for now.
Maybe I should rephrase my question.
Is there a Debian user (64-bit) who can build C-C TB locally since Feb 2?
I am suspecting a subtle regular expression library bug in Debian or
something that caused the build script to create incorrect path string.
(A few years ago, for a period of half a year or longer, Debian's GCC
could not compile mozilla source tree at all. I had to give up any
contribution during that time. So distribution-specific bug may habe
crept in this time.)
Well, as long as I can compile with the patch to take care of the
issue of
strange include path, that is OK, but I am afraid that
the problem may become more difficult to handle and eventually I
wouldn't be able compile C-C TB as in the situation a few years back.
So I want to hear if fellow Debian users are all right for now.
(At least, I have a couple of PCs with Debian suffering from the same
issue
and it suggests it is likely a Debian-specific issue (?). I am perplexed.
I gather mozilla compilation farm uses CentOS.
TIA
I *think* I figured out the issue somehow at least on one of the Debian
installations.
Background: C-C tree has as its subdirectory under ./mozilla, the M-C
source tree.
C-C tree itself has its own HG repository, .hg, and ./mozilla M-C
portion has its own repository under ./mozilla/.hg.
This means that a patch for C-C must be applied under C-C tree's top
directory
and a patch for M-C must be applied under ./mozilla subdirectory.
Problem found:
In my haste to restore at least a compilation-capable environment after the
bug in Bug 1243760 - Replace nsPIDOMWindow with
nsPIDOMWindowInner/Outer in C-C due to bug 1241764 and a few others
rendered the source tree unusable at the end of January, I obtained the
interim patch(es) posted in the related bugzilla entries (I think a few
of serious bugs showed up simultaneously),
and tried to apply them to my local source tree.
I did not realize that the patch(s) was meant for M-C tree and applied
it at the top-most tree of C-C tree. Naturally, the patch failed since
the matching files were not found. But in order to leave .rej files in
the tree, one such failed patch CREATED ./dom directory at the
top-level of C-C source tree (which should have been ./mozilla/dom in
C-C tree's layout ).
In my haste, I reapplied the patch under ./mozilla subdirectory, but never
bothered to remove the .rej file (and the directory) created.
Apparently, this spurious ./dom directory confused the configure/build
script to create the Makefile, et al to produce
-I...top-level-src-of-C-C/dom instead of the proper
-I...top-level-src-of-C-C/mozilla/dom (note the extra /mozilla/ path)
because top-level-src-of-C-C/dom directory existed (!).
This explains why only the headers under mozilla/dom directory were
missing due to incorrect -I path on this computer.
After removing the suprious top-level ./dom directory and a couple
directories that were created to store .rej patch files by incorrect
application of M-C patch(es) at the top-level of C-C source tree
(instead of ./mozilla M-C subtree),
I ran the equivalent of make -f client.mk configure, and all is well.
The compilation went smoothly.
At least on this computer.
I have no idea why the other linux failed in a similar manner.
But it is possible that I have tried to install the same patches to restore
compile-capable environment temporarily and made the same mistake of
applying M-C patch at the top level of C-C sourc tree instead of
./mozilla subdirectory there, too, possibly. Hunan nature being what it
is, the separate HG repositories overlaid in a single source tree is a
source of mistakes...
I won't be able to put my hands on the other computer until Friday. Once
I check it out, I will report back.
TIA
(BTW, I found this extra ./dom directory by happenstance.
I was checking the source tree for improper use of outdated syntax for
octal literal constant [ Bug 1247052 - Improper outdated octal constant
syntax in mailnews/compose/test/unit/test_bug235432.js.
Initially I used find and grep, but then
I found that calendar subdirectory has a tendency to use
ParseInt("0666", 8) style of specification. So I tried to exclude the
directory and only meant to focus on other other directories when I
noticed a strange "dom" directory under C-C source tree top directory!
Short of this happenstance, I will be scratching my head for the rest of
2016 I suppose.)
_______________________________________________
dev-builds mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-builds
