Closed Bug 1252798 Opened 5 years ago Closed 5 years ago

mach file-info gives bogus "Please define JAR_MANIFESTS" error when JAR_MANIFESTS is defined

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(firefox47 affected)

RESOLVED DUPLICATE of bug 1203266
Tracking Status
firefox47 --- affected

People

(Reporter: dbaron, Assigned: gps)

Details

Attachments

(1 file)

In my sourcedir, I get the following error, which seems bogus since there *is* a JAR_MANIFESTS line pointing to the jar.mn!

Maybe related to bug 1241421?


$ ./mach file-info bugzilla-component layout/style/nsCSSRuleProcessor.cpp 
Error running mach:

    ['file-info', 'bugzilla-component', 'layout/style/nsCSSRuleProcessor.cpp']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

SandboxValidationError: 
==============================
ERROR PROCESSING MOZBUILD FILE
==============================

The error occurred while processing the following file or one of the files it includes:

    /hdd/builds/build-mozilla-central/mozilla/layout/style/moz.build

The error occurred when validating the result of the execution. The reported error is:

    A jar.mn exists but it is not referenced in the moz.build file. Please define JAR_MANIFESTS.



  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/mach_commands.py", line 108, in file_info_bugzilla
    for p, m in self._get_files_info(paths, rev=rev).items():
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/mach_commands.py", line 218, in _get_files_info
    return reader.files_info(allpaths)
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/reader.py", line 1374, in files_info
    flags += test_ctx_reader.test_defaults_for_path(path, ctxs)
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/reader.py", line 1422, in test_defaults_for_path
    for obj in emitter.emit_from_context(test_context):
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/emitter.py", line 907, in emit_from_context
    for obj in self._process_jar_manifests(context):
  File "/hdd/builds/build-mozilla-central/mozilla/python/mozbuild/mozbuild/frontend/emitter.py", line 1323, in _process_jar_manifests
    'Please define JAR_MANIFESTS.', context)
This is related to bug 1203266.

Basically, as part of trying to resolve tests metadata we feed an empty Context into the emitter and the emitter is complaining that there is a jar.mn file without the JAR_MANIFESTS entry. I have a feeling the easiest solution for this is a dirty hack...
This is a hack. The tests manifests should be readable in the reader
layer. But we have this nasty interplay between the reader and emitter
causing all kinds of pain. See also bug 1203266.

Review commit: https://reviewboard.mozilla.org/r/37665/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/37665/
Attachment #8725829 - Flags: review?(cmanchester)
Assignee: nobody → gps
Status: NEW → ASSIGNED
Comment on attachment 8725829 [details]
MozReview Request: Bug 1252798 - Add a hack to stop processing after test manifests are read; r?chmanchester

https://reviewboard.mozilla.org/r/37665/#review34225

Can we just land bug 1203266 ? We were considering it blocked on packaging all the test manifest parsers (bug 1215709), but now that I think about it hg mozbuildinfo is already using files_info (which ends up running the emitter to read test manifests anyway), so it wouldn't be a regression.
Attachment #8725829 - Flags: review?(cmanchester)
https://reviewboard.mozilla.org/r/37665/#review34225

As discussed on irc, hg mozbuildinfo appears to be avoiding this because it's using a version of the mozbuild package before bug 1184405 introduced the idea of files_info reading test manifests. 

I rebased bug 1203266, and it fixes this problem, so I'll re-request review there shortly. I don't really mind landing this hack if it comes with a regression test and a FIXME comment explaining the situation.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1203266
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.