Closed Bug 754625 Opened 12 years ago Closed 12 years ago

No such file or directory: '../../../../xpcom/idl-parser/cache' after checking in eae1858ccc6d (Bug 736961)

Categories

(Firefox Build System :: General, defect, P1)

Product:
Firefox Build System
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla15

People

(Reporter: t.matsuu, Assigned: glandium)

References

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

Use idl-parser from $(LIBXUL_DIST)/sdk/bin in comm-central config/rules.mk
2.56 KB, patch
khuey
: review+
Details | Diff | Splinter Review
Use idl-parser from $(LIBXUL_DIST)/sdk/bin
15.18 KB, patch
khuey
: review+
Details | Diff | Splinter Review 
In the case of building Firefox on top of XULRunner, the build is failed as the following:

make[7]: Entering directory `/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/objdir/browser/components/feeds'
make -C public export
make[8]: Entering directory `/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/objdir/browser/components/feeds/public'
mkdir -p /foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/objdir/browser/components/feeds/public/.deps
mkdir -p _xpidlgen/
mkdir -p .deps/
nsIFeedResultService.idl
/usr/bin/python2.7 /foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/config/pythonpath.py \
   \
  -I/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/xpcom/idl-parser \
  /foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/xpcom/idl-parser/header.py --cachedir=../../../../xpcom/idl-parser/cache -I/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/browser/components/feeds/public -I../../../../dist/idl -I/usr/lib64/xulrunner-devel-15/idl /foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/browser/components/feeds/public/nsIFeedResultService.idl -d .deps/nsIFeedResultService.h.pp -o _xpidlgen/nsIFeedResultService.h
Traceback (most recent call last):
  File "/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/config/pythonpath.py", line 52, in <module>
    main(sys.argv[1:])
  File "/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/config/pythonpath.py", line 44, in main
    execfile(script, frozenglobals)
  File "/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/xpcom/idl-parser/header.py", line 499, in <module>
Traceback (most recent call last):
  File "/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/config/pythonpath.py", line 52, in <module>
    main(sys.argv[1:])
  File "/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/config/pythonpath.py", line 44, in main
    os.mkdir(options.cachedir)
OSError    : [Errno 2] No such file or directory: '../../../xpcom/idl-parser/cache'
execfile(script, frozenglobals)
  File "/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/xpcom/idl-parser/header.py", line 499, in <module>
    os.mkdir(options.cachedir)
OSError: [Errno 2] No such file or directory: '../../../../xpcom/idl-parser/cache'
make[8]: make[7]: *** [_xpidlgen/fuelIApplication.h] Error 1*** [_xpidlgen/nsIFeedResultService.h] Error 1

rm _xpidlgen/.mkdir.donerm _xpidlgen/.mkdir.done .deps/.mkdir.done .deps/.mkdir.done

make[7]: Leaving directory `/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/objdir/browser/fuel/public'
make[8]: Leaving directory `/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/objdir/browser/components/feeds/public'
make[6]: *** [export] Error 2
make[7]: *** [export] Error 2
make[6]: Leaving directory `/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/objdir/browser/fuel'
make[7]: Leaving directory `/foo/rpmbuild/BUILD/firefox-15.0/mozilla-central/objdir/browser/components/feeds'
make[5]: *** [fuel_export] Error 2
Summary: No such file or directory: '../../../../xpcom/idl-parser/cache' after checking in eae1858ccc6d → No such file or directory: '../../../../xpcom/idl-parser/cache' after checking in eae1858ccc6d (Bug 736961)
I get bug 754642 too, on Linux, gcc.
I was able to build SeaMonkey after:
- pulling current trunk
- cleaning my objdir
- deleting mozilla/xpcom and doing hg up -C to rewrite it
There are two possible solutions:

1. Use os.mkdirs instead of os.mkdir to generate cachedir
xpcom/idl-parser/header.py:
     if options.cachedir is not None:
         if not os.path.isdir(options.cachedir):
             os.mkdir(options.cachedir)
         sys.path.append(options.cachedir)

2. "make export" at xpcom/idl-parser before parsing idl files
xpcom/idl-parser/Makefile.in:
# Generate the PLY lexer and parser.
export:: $(PARSER_SRCS) $(PLY_PROGS)
	$(PYTHON_PATH) \
	  $(PLY_INCLUDE) \
	  -I$(topsrcdir)/xpcom/idl-parser \
	  $(topsrcdir)/xpcom/idl-parser/header.py --cachedir=$(DEPTH)/xpcom/idl-parser/cache --regen
What is causing us to parse idl files before we get to 'export' in xpcom/idl-parser?
(In reply to Karsten Düsterloh from comment #3)
> I was able to build SeaMonkey after:
> - pulling current trunk
> - cleaning my objdir
> - deleting mozilla/xpcom and doing hg up -C to rewrite it

This is what can be called a one-time-workaround. It works, but only once. The second time we make an update and build, we are back to the beginning again..
I realized that c-c config/rules.mk also contains two references to a cachedir pointing to $(MOZILLA_DIR)/xpcom/idl-parser which should probably be amended too. Dunno if that's the issue, trying to sync them too.
The easy way out would be to use the scripts from $(LIBXUL_DIST)/sdk/bin instead of $(topsrcdir)/xpcom/idl-parser, and not set a cachedir at all.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5)
> What is causing us to parse idl files before we get to 'export' in
> xpcom/idl-parser?

In case of Firefox-on-Xulrunner, we don't export in xpcom/idl-parser. The real solution is comment 8.
Attachment #623616 - Flags: review?(khuey)
Here's the comm-central similar patch, currently building here..
Attachment #623627 - Flags: review?(khuey)
(In reply to Mike Hommey [:glandium] from comment #10)
> Created attachment 623616 [details] [diff] [review]
> Use idl-parser from $(LIBXUL_DIST)/sdk/bin

Note that in addition to that patch i also needed to "fix" xpcom/typelib/xpidl/Makefile.in :

-  $(DEPTH)/xpcom/idl-parser/cache/xpidllex.py \
-  $(DEPTH)/xpcom/idl-parser/cache/xpidlyacc.py \
+  $(DEPTH)/xpcom/idl-parser/xpidllex.py \
+  $(DEPTH)/xpcom/idl-parser/xpidlyacc.py \

That properly installed those files to sdk/bin
Attachment #623616 - Attachment is obsolete: true
Attachment #623616 - Flags: review?(khuey)
Attachment #623637 - Flags: review?(khuey)
Thunderbird is (partly) affected too.
Severity: normal → blocker
Flags: in-testsuite-
OS: Linux → All
Priority: -- → P1
Product: Firefox → Core
QA Contact: build.config → build-config
Hardware: x86_64 → All
Target Milestone: --- → mozilla15
Version: unspecified → Trunk
I had to 'hg backout eae1858ccc6d' to make TB build again. What is the definition of "partly"?
(In reply to :aceman from comment #15)
> What is the definition of "partly"?

I meant that not all (SM and TB) builds are broken: I'm guessing they haven't been clobbered (or whatever) yet...
Attachment 623637 [details] [diff] works fine for Firefox on top of XULRunner.
And attachment 623627 [details] [diff] [review] works fine for Thunderbird (not on top of XULRunner because of bug 306324).
Do they work in a build with no objdir?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #19)
> Do they work in a build with no objdir?

They probably don't. --regen should just remove xpidllex and xpidlyacc, instead of *.
It seems to make more sense to me to back out bug 736961 and fix it differently then.
With restricted removals.
Attachment #623679 - Flags: review?(khuey)
Attachment #623637 - Attachment is obsolete: true
Attachment #623637 - Flags: review?(khuey)
Assignee: nobody → mh+mozilla
Landed the m-c part:
https://hg.mozilla.org/mozilla-central/rev/9e5b25074f9f
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
SeaMonkey error has changed to
"OSError: [Errno 2] No such file or directory: './xpidllex.py'"

What about the c-c part?
(In reply to Serge Gautherie (:sgautherie) from comment #24)
> SeaMonkey error has changed to
> "OSError: [Errno 2] No such file or directory: './xpidllex.py'"
> 
> What about the c-c part?

Is this with or without attachement 623627 ?
(In reply to Landry Breuil (:gaston) from comment #25)
> Is this with or without attachement 623627 ?

With comment 23 changeset, without c-c part which hasn't been pushed yet: hence my question.
There's a pending fixup for the m-c part anyways.
tbpl for tb-trunk seems happy with it :
https://tbpl.mozilla.org/?tree=Thunderbird-Trunk&rev=e6c1bac57163
Assignee: mh+mozilla → nobody
Severity: blocker → normal
OS: All → Linux
Priority: P1 → --
Hardware: All → x86_64
Target Milestone: mozilla15 → ---
Version: Trunk → unspecified
argh.
Assignee: nobody → mh+mozilla
Severity: normal → blocker
OS: Linux → All
Priority: -- → P1
Hardware: x86_64 → All
Target Milestone: --- → mozilla15
Version: unspecified → Trunk
V.Fixed, per SeaMonkey TBPL too.
Status: RESOLVED → VERIFIED
Confirming fix in TB when I updated with hg.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: