Traverse js/src moz.builds from top-level configure.

RESOLVED FIXED in mozilla30

Status

defect
RESOLVED FIXED
5 years ago
Last year

People

(Reporter: glandium, Assigned: glandium)

Tracking

(Blocks 1 bug)

24 Branch
mozilla30
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 1 obsolete attachment)

Assignee

Description

5 years ago
This is the second and last step before completely getting rid of js/src/configure.in. This is about making js/src and top-level one build-system, at the make level.
Assignee

Updated

5 years ago
Depends on: 462427
Assignee

Updated

5 years ago
Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
Assignee

Comment 3

5 years ago
We happen to be lucky currently because e.g. build is created by config.status
before we subconfigure in build/clang-plugin. But further changes break that
luck.
Attachment #8372027 - Flags: review?(gps)
Assignee

Updated

5 years ago
Depends on: 946687, 968537, 968561
Assignee

Updated

5 years ago
Attachment #8372025 - Attachment is obsolete: true
Attachment #8372025 - Flags: review?(gps)
Assignee

Comment 6

5 years ago
Before, we would run configure in both top-level and js/src, and both
configures would traverse their own set of moz.builds, without actual
knowledge about the other. With this change, both configures still run,
but only top-level traverses moz.build files, and uses js/src's
config.status when traversing its moz.build files. This allows a better
sharing of information between both build systems and the removal of many
hacks.

This also moves running libffi and icu configure to top-level.

Standalone js builds still have their own configure doing moz.build traversal,
as before.

https://tbpl.mozilla.org/?tree=Try&rev=edbdaa406db4

(the Hf, r and ggc reds are addressed in this patch and in the try push for the next patch)
Attachment #8372189 - Flags: review?(gps)
Assignee

Comment 7

5 years ago
Before making top-level traverse js/src moz.build files, there was a need to
distinguish between top-level traversing e.g. top-level moz.build or
config/moz.build and js/src traversing them. With a single traversal of both
moz.build sets, we now only need to distinguish between js standalone builds
and gecko builds.

There is still, however, a need to distinguish between top-level vs. js/src
configure runs on gecko builds to make them subconfigure icu and libffi from
top-level instead of js/src in js standalone builds, or when choosing to make
js/src's config.status do something when run or not.

https://tbpl.mozilla.org/?tree=Try&rev=a7445e1bf1d6
Attachment #8372190 - Flags: review?(gps)
Assignee

Comment 8

5 years ago
(In reply to Mike Hommey [:glandium] from comment #5)
> Created attachment 8372187 [details] [diff] [review]
> Use per-directory config in sandboxes when reading moz.builds
> 
> Up to this patch: https://tbpl.mozilla.org/?tree=Try&rev=79c8b03d356b

I should mention that i could convert EXTERNAL_SOURCE_DIR to use this, but a couple weeks away from it being obsolete, I didn't want to risk breaking comm-central by touching it.
Comment on attachment 8372185 [details] [diff] [review]
Move libffi subconfigure invocation in build/autoconf/ffi.m4

Review of attachment 8372185 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM.
Attachment #8372185 - Flags: review?(gps) → review+
Comment on attachment 8372026 [details] [diff] [review]
Move icu subconfigure invocation in build/autoconf/icu.m4

Review of attachment 8372026 [details] [diff] [review]:
-----------------------------------------------------------------

Looked at this side-by-side and didn't see any major differences.
Attachment #8372026 - Flags: review?(gps) → review+
Attachment #8372027 - Flags: review?(gps) → review+
Comment on attachment 8372187 [details] [diff] [review]
Use per-directory config in sandboxes when reading moz.builds

Review of attachment 8372187 [details] [diff] [review]:
-----------------------------------------------------------------

Nice.
Attachment #8372187 - Flags: review?(gps) → review+
Comment on attachment 8372189 [details] [diff] [review]
Traverse js/src moz.builds from top-level configure

Review of attachment 8372189 [details] [diff] [review]:
-----------------------------------------------------------------

Awesome patch. Would r+ again.

Some comments in /moz.build before checkin wouldn't hurt.

::: build/autoconf/ffi.m4
@@ +28,1 @@
>  if test "$BUILD_CTYPES" -a -z "$MOZ_NATIVE_FFI"; then

No reindent?

::: build/autoconf/icu.m4
@@ +140,1 @@
>  if test -n "$ENABLE_INTL_API" -a -z "$MOZ_NATIVE_ICU"; then

No reindent?

::: python/mozbuild/mozbuild/frontend/reader.py
@@ +169,5 @@
>          relpath = mozpath.relpath(path, topsrcdir)
>          reldir = mozpath.dirname(relpath)
>  
> +        if mozpath.dirname(relpath) == 'js/src' and \
> +                not config.substs.get('JS_STANDALONE'):

This seems hacky. Meh.
Attachment #8372189 - Flags: review?(gps) → review+
Comment on attachment 8372190 [details] [diff] [review]
Replace most BUILDING_JS uses with JS_STANDALONE

Review of attachment 8372190 [details] [diff] [review]:
-----------------------------------------------------------------

This was an awesome patch series.
Attachment #8372190 - Flags: review?(gps) → review+

Updated

5 years ago
Depends on: 970757
Assignee

Updated

5 years ago
Blocks: 988141
Assignee

Updated

5 years ago
Depends on: 1077228

Updated

Last year
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.