Closed Bug 1337391 Opened 3 years ago Closed 3 years ago

certdata.c isn't generated when building the export tier

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(firefox52 unaffected, firefox53 wontfix, firefox54 fixed)

RESOLVED FIXED
mozilla54
Tracking Status
firefox52 --- unaffected
firefox53 --- wontfix
firefox54 --- fixed

People

(Reporter: ehsan, Assigned: glandium)

References

Details

(Keywords: regression)

Attachments

(1 file)

STR:

$ ./mach clobber
$ ./mach configure &$& ./mach build-backend
$ make -C objdir pre-export && make -C objdir export
$ ls objdir/security/nss/lib/ckfw/builtins/builtins_nssckbi/certdata.c # The file isn't found.
$ cd objdir/security/nss/lib/ckfw/builtins/builtins_nssckbi && make export
$ ls certdata.c # The file is found now.

As far as I can tell, this is caused by "security/nss/lib/ckfw/builtins/builtins_nssckbi/target" not existing in the export_dirs variable in root.mk, and only in compile_dirs.

Ted, can you please take a look?  Thanks!
Flags: needinfo?(ted)
Blocks: 1328454
We map the gyp action directly to a moz.build GENERATED_FILES:
https://dxr.mozilla.org/mozilla-central/rev/f4f374622111022d41dd8d5eb9220624135c534a/python/mozbuild/mozbuild/frontend/gyp_reader.py#94

And GENERATED_FILES are supposed to be built in the export tier. The recursivemake backend has code specifically to look at GENERATED_FILES to do this:
https://dxr.mozilla.org/mozilla-central/rev/f4f374622111022d41dd8d5eb9220624135c534a/python/mozbuild/mozbuild/backend/recursivemake.py#510

Unfortunately I'm not super familiar with the way the recursivemake backend works beyond that these days, so I don't know what exactly is going wrong there. glandium or one of the other build peers would be better equipped to handle that question.
Flags: needinfo?(ted)
Relying on tiers is not future-proof. Nothing guarantees that something will be built in a specific tier forever. As a matter of fact, this is what is happening here. If you need that file to be built, use mach build security/nss/lib/cfkw/builtins/builtins_nssckbi/certdata.c, but even that is not really future-proof either: the path might (and will likely) change.
The use case here is to ensure that all of the headers and the generated sources are current (basically everything that a C++ compiler consumes.  The third command in comment 0 achieves this, except for this one file in the whole tree...
Turns out there's actually a nasty bug hidden, triggered by the gyp code. Never was a problem before nss got gypped.
Assignee: nobody → mh+mozilla
This is actually a regression from bug 1308982.
Blocks: 1308982
Comment on attachment 8835310 [details]
Bug 1337391 - Don't skip all directories that aren't traversed with a DIRS in a moz.build file.

https://reviewboard.mozilla.org/r/111000/#review112546

Regarding the commit message, this was broken prior to bug 1308982 -- the patch there codified the existing (incorrect) behavior.
Attachment #8835310 - Flags: review?(cmanchester) → review+
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/8857aa03d1a5
Don't skip all directories that aren't traversed with a DIRS in a moz.build file. r=chmanchester
Thanks for the quick fix!
https://hg.mozilla.org/mozilla-central/rev/8857aa03d1a5
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Looks like this needs an Aurora approval request as well.
Flags: needinfo?(mh+mozilla)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #11)
> Looks like this needs an Aurora approval request as well.

It doesn't _actually_ matter enough for an uplift. It only affects intermediary files in NSS, and those files are being depended upon through other means, and are built correctly through a full build.

(That is, except if Ehsan is planning on trying to do the same thing with aurora)
Flags: needinfo?(mh+mozilla)
Ehsan, how much do you care about whether this reaches Aurora or not?
Flags: needinfo?(ehsan)
No not at all, it's OK to not backport this.
Flags: needinfo?(ehsan)
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.