250032 - 1.7 branch can't be clobber built

Status: RESOLVED WORKSFORME

(SeaMonkey :: Build Config, defect)

Description

[Dan M]

I've been bumbling around on this for hours and run into a wall. It seems like a
serious problem. I wonder if one of you guys would verify and -- ahem -- fix it.
And if the problem is real, kill KILL **KILL!!** whoever is responsible for such
obvious breakage, even though I haven't been able to pin down a checkin. Damnit
things like this should be tested before checking in.

I use a slightly modified build system so, heh, maybe that's my problem. It's
easy to check. I'm using Windows and building a 1.7 branch debug build. (Windows
is the only OS for which there is currently no 1.7 Tinderbox). This happens to
me only on the 1.7 branch. Not the trunk. Not Aviary.

It's easy to test. From scratch, on Windows, pull 1.7 and try to make a debug
build. (I haven't tried optimized.) The compilation phase should fail within
minutes. Or if you already have such a build lying around, try this:

cd <mozilla>/xpcom/obsolete
rm _xpidlgen/nsIFileSpec.xpt _xpidlgen/.done
make

(Note for the purposes of this test it's not necessary to remove
_xpidlgen/.done, but I want to be certain...) Only some directories are
affected. For example there is no trouble with xpcom/base. Here's another broken
one:

cd <mozilla>/modules/libpr0n/decoders/icon
rm _xpidlgen/nsIIconURI.xpt _xpidlgen/.done
make

Do these succeed? Then I alone am exquisitely boned and you can close this bug.
If it fails for you too then the 1.7 branch obviously has a serious build problem.

Note the .h files *are* built. It's only the .xpt files that are not built. So a
depend build would appear to compile, but have problems in its JS bindings.

---

Here's what little I know. It's not the fault of xpidl.exe. The build system
simply fails to emit the command for generating the .xpt files, and only in
certain directories. I've been able to find no obvious pattern to the makefiles
in affected directories. But a directory that fails will fail every time.

The corresponding section of rules.mk, around line 1330, goes like this (note I
wrapped the last line to save horizontal scrolling in this bug report):

ifndef NO_GEN_XPT
# generate intermediate .xpt files into $(XPIDL_GEN_DIR), then link
# into $(XPIDL_MODULE).xpt and export it to $(DIST)/bin/components.
$(XPIDL_GEN_DIR)/%.xpt: %.idl $(XPIDL_COMPILE) $(XPIDL_GEN_DIR)/.done
  $(REPORT_BUILD)
  $(ELOG) $(XPIDL_COMPILE) -m typelib -w -I $(IDL_DIR) -I$(srcdir)
                           -o $(XPIDL_GEN_DIR)/$* $(_VPATH_SRCS)

I've been able to hack a 1.7 branch to build to completion by removing the
compiler dependency. That is:

- $(XPIDL_GEN_DIR)/%.xpt: %.idl $(XPIDL_COMPILE) $(XPIDL_GEN_DIR)/.done
+ $(XPIDL_GEN_DIR)/%.xpt: %.idl $(XPIDL_GEN_DIR)/.done

I have no idea what this is actually doing. Obviously there is an xpidl compiler
and the variable specifying it is correct. Otherwise the corresponding action
would fail. A dump of all build variables used in these rules seems to show that
they're all undamaged. I've been able to track down no important-looking
differences in recursive diffs between 1.7 and Aviary in the xpcom or config
directories. (Again, Aviary doesn't have this problem, and there's less noise
than between 1.7 and the trunk, where a licensing change has been checked in.)

I've run into a wall. Anybody wanna pick this up?

Comment 1

[Dan M]

PS sorry for assigning it to you, leaf. But the default choice of
[e-mail] was unsatisfying.

Comment 2

[Daniel (Leaf) Nunes]

No worries, dan. I can't reproduce this with a *non* debug build:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Branch/1089179280.5585.gz&fulltext=1

The cycle is orange because of a packaging configuration failure i'm working on
still.

I'll try a debug build now (i only saw the mail, not the bug until this morning,
so i didn't know it was a debug build only problem) on my personal build machine.

Comment 3

[Dan M]

It turns out I can build optimized, too. So this seems to affect only debug
builds of the 1.7 branch. Less critical then, I suppose. Still curious to see
whether it's somehow only my machine that's affected.

Comment 4

[Daniel (Leaf) Nunes]

Ok, so i just did:
make -f client.mk checkout
make -f client.mk clobber_all
make -f client.mk build
without issue on my local 1.7 tree on windows xp, using msvc 6, without any
mozconfig or configure options (which defaults to debug, which i confirmed by
looking at autoconf.mk and the compile lines, which all have the debug flags set).

You said before that your build system is locally modified.... do you want to
attach some diffs so we can maybe spot what the issue is? There's no error for
you, just a silent failure to build .xpt files?

Comment 5

[Dan M]

Hmm yes, I see trunk builds became optimized by default on May 1st, several
weeks after the 1.7 branch was cut, and that the branch appears to still be
debug by default.

Yup, I get no error, just a silent failure. Until the system wants one of those
missing .xpt files, that is. I was able to build a 1.7 branch the last time I
tried, which was maybe mid-June.

My build system is standard, except I don't use .mozconfig. I create my own
|configure| using autoconf, and I run |configure| using my own set of
--enable-XXX flags from a batch file on my machine. The set I use for Firefox is
adapted from browser/config/mozconfig. I do it this way only because my build
system is older than .mozconfig, or at least before it became popular, and we've
grown to appreciate each other. Until now. I haven't updated cygwin since last
October.

Eyeballing, the difference seems to be that I add --disable-tests and
--enable-chrome-format=flat, I explicitly add --enable-debug and
--disable-optimize, and I omit both --disable-profile-sharing and
--enable-single-profile. I guess I could try removing those differences to see
if they somehow make it better.

I've also occasionally had some grief with the fact that my build drive is
cygwin mounted both as the required and horrible /cygdrive/d/ and as the
convenient and likeable /d/. I've had some grief from that before, but not this
kind of grief.

It appears that indeed I am exquisitely boned. Leaf if something jumps out at
you by all means say something but I guess I'll just slap this one shut.

Comment 6

[Dan M]

Errrr and by "batch file" I of course mean bash shell script.

Comment 7

[Daniel (Leaf) Nunes]

Well, you're not *totally* boned, right? you have a workaround that gets the xpt
files generated. I'm not sure why having the xpidl compiler on a dependency line
prevents the xpt file from being built, though, when it plainly exists.

Comment 8

[Dan M]

My boneage is miminal, but exquisite. I have a workaround, but it's like falling
and breaking a hip (I guess). "That sucked," I'm thinking. "Gee I hope the rest
of my bones are OK."