Should an empty file trigger "No preprocessor directives found" error?
If not, then the following fix is useful.
# HG changeset patch
# User ISHIKAWA, Chiaki <ishik...@yk.rim.or.jp>
# Parent c758de14f7bb355b8c0696c9dd3207bffe75f4aa
Ignore no preprocessing directive for a zero-sized file!?
diff --git a/python/mozbuild/mozbuild/preprocessor.py
b/python/mozbuild/mozbuild/preprocessor.py
--- a/python/mozbuild/mozbuild/preprocessor.py
+++ b/python/mozbuild/mozbuild/preprocessor.py
@@ -314,17 +314,19 @@ class Preprocessor:
self.includes = set()
self.silenceMissingDirectiveWarnings = False
if defines:
self.context.update(defines)
def failUnused(self, file):
msg = None
if self.actionLevel == 0 and not
self.silenceMissingDirectiveWarnings:
- msg = 'no preprocessor directives found'
+ # Only set this if file size is NOT zero
+ if os.path.getsize(file) != 0:
+ msg = 'no preprocessor directives found'
elif self.actionLevel == 1:
msg = 'no useful preprocessor directives found'
if msg:
class Fake(object): pass
fake = Fake()
fake.context = {
'FILE': file,
'LINE': None,
Background
In the last few days, I saw build bustage of C-C TB
due to DIST_FILES no longer a valid variable in moz.build
infrastructure.
There has been a renaming:
I see some bugzillas when I search for DIST_FILES
1177710 Move DIST_FILES support out of rules.mk
1163441 Use FINAL_TARGET_FILES and PP_TARGETS (instead of DIST_FILES)
for Thunderbird themes
1229803 Port Bug 1228444 (Rename DIST_FILES to FINAL_TARGET_PP_FILES) to
DOM Inspector
The direct problem of DIST_FILES seems to be gone by now due to
patches landing.
I fetched a few patches from bugizilla.
Then when I tried build on tryserver and local PC, I saw the following
error during preprocessing of a file called channel-prefs.py.
Exporting extension to source/test/addons/layout-change.xpi.
make[2]: Circular /NREF-COMM-CENTRAL/comm-central/mozilla/CLOBBER <-
/NREF-COMM-CENTRAL/comm-central/mozilla/CLOBBER dependency dropped.
adding: install.rdf (deflated 52%)
adding: plugins/libnptest.so (deflated 67%)
adding: plugins/libnpsecondtest.so (deflated 67%)
adding: plugins/libnpthirdtest.so (deflated 67%)
adding: plugins/libnpswftest.so (deflated 67%)
adding: plugins/libnpctrltest.so (deflated 67%)
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File
"/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/action/preprocessor.py",
line 18, in <module>
main(sys.argv[1:])
File
"/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/action/preprocessor.py",
line 14, in main
pp.handleCommandLine(args, True)
File
"/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/preprocessor.py",
line 483, in handleCommandLine
self.processFile(input=input, output=out)
File
"/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/preprocessor.py",
line 388, in processFile
self.failUnused(input.name)
File
"/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/preprocessor.py",
line 332, in failUnused
raise Preprocessor.Error(fake, msg, None)
mozbuild.preprocessor.Error:
('/NREF-COMM-CENTRAL/comm-central/mail/app/profile/channel-prefs.js',
None, 'no preprocessor directives found', None)
Makefile:122: recipe for target 'libs' failed
make[4]: *** [libs] Error 1
/NREF-COMM-CENTRAL/comm-central/mozilla/config/recurse.mk:79: recipe for
target 'mail/app/libs' failed
make[3]: *** [mail/app/libs] Error 2
The preprocessor complained that the file contained no preprocessing
directive.
Given the discussion in the bugzilla entries, especially the later
ones, about some variable names with _PP_ in it which indicates that
the file thus referenced by such variables are preprocessed,
my initial kludge to get past by this bug was to
remove channel-prefs.py from inclusion of this file into moz.build a
la my local patch:
# HG changeset patch
# User ISHIKAWA, Chiaki <ishik...@yk.rim.or.jp>
# Parent a593ef73da269fdeeb11847f33970aba32717b2f
do not run preprocessing of channel-prefs.js?
diff --git a/mail/app/moz.build b/mail/app/moz.build
--- a/mail/app/moz.build
+++ b/mail/app/moz.build
@@ -46,11 +46,10 @@ DEFINES['APP_VERSION'] = CONFIG['MOZ_APP
if CONFIG['MOZILLA_OFFICIAL']:
DEFINES['MOZILLA_OFFICIAL'] = True
DISABLE_STL_WRAPPING = True
JS_PREFERENCE_FILES += [
'profile/all-thunderbird.js',
- 'profile/channel-prefs.js',
]
But, no. It did not seem to solve the problem.
Since I need to get the local build going to track down strange
windows test issues which occurred on tryserver, I wanted to make sure
that my tree is compilable, at least under linux, before submitting
windows build request to tryserver, and thus was forced to tweak the
preprocessor to ignore this issue: i.e., not finding preprocessor
directive for a file that is preprocessed possibly suggests a
misconfiguration, but a developr temporarily can live with it.
As I try to tweak the preprocessor and find out what was going on
I found to my surprise that the channel-pref.js was empty, a file of 0
octet length (!)
Maybe my tweaking moz.build or something erased the file.
A preprocessor certainly complains that there is no pre-processor
directive in it. It is empty after all.
I have no idea why I came into this strange c-c tree status.
But I wanted to get the compilation going. I can live with temporal
build issue on the try server.
So again, my brute force fix was
to NOT issue the warning and return error status when the
preprocessed file is EMPTY.
Thus the patch at the beginning.
OK, this gets me going locally until I hit another bug on tryserver.
I think this is a new bug caused by the mismatch of mozconfig.cache in
C-C and M-C (the latter was changed for some PGO build flags or
something.).
I *THINK* the issues mentioned above on tryserver are solved in the C-C
tree somehow by newer patches now and
so maybe my rumbling above may not matter match any more.
But still I have this nagging question:
Should an empty file trigger "No preprocessor directives found" error?
PS: BTW, I noticed a serious problem while trying to fix a problem.
Doesn't tryserver have a serious performance issue in the sense
that when a build request fails, sometimes it still runs the tests
anyway using old (possibly stale or unintended object)?
Case in point:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=ea768edd7c1d&selectedJob=12724
In this case, the build itself failed, but test were executed.
I wonder which binary it is using: I assume that it uses a binary left
over from the previous (successful) build (!?) But a build request is
very often sent by a developer to test a NEW patch and so running
tests when BUILD fails seems to be a WASTE of CPU time. No? At least
in the case above, I was embarrassed that tryserver runs some outdated
binary, which is not my intention at all.
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
