If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

export in Makefile is no longer taken into account

RESOLVED WONTFIX

Status

()

Core
Build Config
RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: Fallen, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
STR:

* Add Makefile in subdir/ that has:
      export USE_EXTENSION_MANIFEST = 1
* Add a moz.build in that directory that includes other dirs via DIRS

Results: 

* The export is not honored when building in make -C objdir
* The export *is* taken into account when calling make -C objdir/subdir

Unfortunately we are missing some nightly builds, but it happened some time between 2014-07-25 and 2014-08-04. The above steps apply to Lightning using the comm-central build system so there might be slight differences. I hope you can help me find the root cause and tell me if this is an issue with the build system or if I have to make changes calendar/.

Example usage:

http://mxr.mozilla.org/comm-central/source/calendar/lightning/Makefile.in#15
http://mxr.mozilla.org/comm-central/source/calendar/lightning/moz.build

(USE_EXTENSION_MANIFEST unset in:)
http://mxr.mozilla.org/comm-central/source/calendar/base/jar.mn
(Reporter)

Updated

3 years ago
Blocks: 1049201
Relying on "export" to propagate down to subdirectories was wrong in the first place. Just define USE_EXTENSION_MANIFEST everywhere it needs to be set.
(Reporter)

Comment 2

3 years ago
We used this to separate general calendaring components from those related to the Lightning extension: something in calendar/base does not necessarily have to be part of Lightning, therefore USE_EXTENSION_MANIFEST and XPI_NAME don't always apply. 

This originated from times where we still had Sunbird, so you could argue that its time to change this, but this would mean I need to define USE_EXTENSION_MANIFEST in every calendar/ directory, adding in Makefile.in's where we've already gotten rid of them in favor of moz.build. Shouldn't exporting rather be fixed? Similarly XPI_NAME is also exported, but this is done in moz.build where it seems to work.
(Reporter)

Comment 3

3 years ago
Ok, its not actually that bad, I just need to define USE_EXTENSION_MANIFEST in every directory that has a jar.mn and they all currently have a Makefile.in anyway.

I guess your goal is to get rid of the Makefiles alltogether so exports don't have to work there, but if someone is expecting an export to work then this might bite them. Its used in a few locations in m-c too:

http://mxr.mozilla.org/mozilla-central/search?string=^export+&regexp=on&find=Makefile.in

As we have a workaround I'm fine with having this bug closed, but maybe you want to keep it open to fix the regression. I'll leave that up to you.
If someone is expecting an export to work, it hasn't worked for months on mozilla-central, so they've been broken for months. C-c only switched to the new directory traversal recently, and it's impossible to "fix" export in it, and the old directory traversal is gone.
(Reporter)

Comment 5

3 years ago
Ah ok, I didn't know it has been this way for m-c for a while. I'll leave that to specific bugs then and close this one. Thanks for the info!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.