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

mach build <module>/ doesn't process EXPORTS

NEW
Unassigned

Status

()

Core
Build Config
2 years ago
2 years ago

People

(Reporter: mayhemer, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
Having a header in EXPORTS in a module's moz.build doesn't copy it to <obj>/dist/include on a change.  Only a full build does.

Updated

2 years ago
Severity: major → normal
Component: mach → Build Config

Comment 1

2 years ago
How did you perform a build that missed the copy?
Flags: needinfo?(honzab.moz)
(Reporter)

Comment 2

2 years ago
(In reply to Gregory Szorc [:gps] from comment #1)
> How did you perform a build that missed the copy?

Sorry for the lag.  Note that I'm on windows.

so, first I've added a new header /tools/profiler/backtrack/Backtrack.h.  Then I've MODIFIED the existing /tools/profiler/moz.build to export that new header as:

if CONFIG['MOZ_BACKTRACK']:
    EXPORTS += [
        'backtrack/Backtrack.h',
    ]
    UNIFIED_SOURCES += [
        'backtrack/Backtrack.cpp',
    ]

MOZ_BACKTRACK definitely is defined because backtrack/Backtrack.cpp is being built.  And I've checked the header is being exported on full build (./mach build) in _obj/dist/include.


STR:
- modify or touch the /tools/profiler/backtrack/Backtrack.h
- ./mach build tools/profiler/

Actual:
I can see Unified_cpp_tools_profiler0.cpp is rebuilt (sources include that header).  But _obj/dist/include contains the old (unmodified) version of the header.

Expected:
obj/dist/include/Backtrack.h be updated.


This is a problem when you modify the header and then do e.g. |./mach build tools/profiler/ xpcom/| where some CPP file under xpcom includes and uses that header.  The changes will not propagate.


For a patch to test with you can check bug 1148204, built with --enable-backtrack configure option.
Flags: needinfo?(honzab.moz)

Comment 3

2 years ago
Copying of headers to dist/include occurs in a make rule in the root Makefile. We don't invoke this rule in partial builds (e.g. `mach build tools/profiler`). We (strangely) do process the rule to install things into dist/idl.

I suspect things picked up the header changes because of a -I$(srcdir) argument despite the changes not being in dist/include.

One workaround is to run `mach build binaries`, which will process the dist/include installs. We could potentially also process the dist/include installs for partial directory builds.

Is there a reason you aren't running `mach build binaries`?
Flags: needinfo?(honzab.moz)
(Reporter)

Comment 4

2 years ago
(In reply to Gregory Szorc [:gps] from comment #3)
> Is there a reason you aren't running `mach build binaries`?

I'm not sure if there is a reason not to.  I probably didn't want to run it because I wanted to tune out only xpcom changes dependent on the header in tools and not rebuild everything else that is including it.  That header was spread around and the speed would be nearly same as full ./mach build.  So, I was using build over specific modules to speed up.
Flags: needinfo?(honzab.moz)
You need to log in before you can comment on or make changes to this bug.