Closed Bug 976896 Opened 6 years ago Closed 6 years ago

Port STL_FLAGS to moz.build

Categories

(Firefox Build System :: General, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla30

People

(Reporter: ehsan, Assigned: ehsan)

References

Details

Attachments

(1 file, 1 obsolete file)

For the most part, we use this flag to disable STL wrapping.  There are a couple of places (memory/mozalloc/Makefile.in and dom/plugins/ipc/hangui/Makefile.in) where this is abused to set CXXFLAGS.  I'm planning to add a moz.build variable called DISABLE_STL_WRAPPING, and have it emit |STL_FLAGS := | when it's set to True, and convert those abuse cases to CXXFLAGS.

Does that sound good?
Flags: needinfo?(mshal)
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(gps)
As long as you also properly set DISABLE_STL_WRAPPING if STL_FLAGS were replaced by a new value, and ensure the ordering doesn't matter for those flags STL_FLAGS was abused for.
Flags: needinfo?(mshal)
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(gps)
(In reply to comment #1)
> As long as you also properly set DISABLE_STL_WRAPPING if STL_FLAGS were
> replaced by a new value, and ensure the ordering doesn't matter for those flags
> STL_FLAGS was abused for.

The ordering shouldn't matter since they're just -D commands.

Is there a way to just disallow STL_FLAGS in Makefile.in so that I don't have to set DISABLE_STL_WRAPPING if STL_FLAGS is replaced by a new value?
Flags: needinfo?(mh+mozilla)
Replace $(STL_FLAGS) in COMPILE_CXXFLAGS with $(if $(DISABLE_STL_WRAPPING),,$(STL_FLAGS)), and just make the backend produce DISABLE_STL_WRAPPING?
Flags: needinfo?(mh+mozilla)
(In reply to comment #3)
> Replace $(STL_FLAGS) in COMPILE_CXXFLAGS with $(if
> $(DISABLE_STL_WRAPPING),,$(STL_FLAGS)), and just make the backend produce
> DISABLE_STL_WRAPPING?

OK, sounds good!
Attached patch Port STL_FLAGS to moz.build (obsolete) — Splinter Review
Attachment #8384166 - Flags: review?(mshal)
Attachment #8384166 - Flags: review?(mh+mozilla)
Attachment #8384166 - Flags: review?(gps)
Attachment #8384166 - Attachment is obsolete: true
Attachment #8384166 - Flags: review?(mshal)
Attachment #8384166 - Flags: review?(mh+mozilla)
Attachment #8384166 - Flags: review?(gps)
Attachment #8384346 - Flags: review?(mshal)
Attachment #8384346 - Flags: review?(mh+mozilla)
Attachment #8384346 - Flags: review?(gps)
Comment on attachment 8384346 [details] [diff] [review]
Port STL_FLAGS to moz.build

>diff --git a/memory/build/replace_malloc.h b/memory/build/replace_malloc.h
>index 371e824..c98e2c8 100644
>--- a/memory/build/replace_malloc.h
>+++ b/memory/build/replace_malloc.h
>@@ -49,17 +49,18 @@
>  * Building a replace-malloc library is like rocket science. It can end up
>  * with things blowing up, especially when trying to use complex types, and
>  * even more especially when these types come from XPCOM or other parts of the
>  * Mozilla codebase.
>  * It is recommended to add the following to a replace-malloc implementation's
>  * Makefile.in:
>  *   MOZ_GLUE_LDFLAGS = # Don't link against mozglue
>  *   WRAP_LDFLAGS = # Never wrap malloc function calls with -Wl,--wrap
>- *   STL_FLAGS = # Avoid STL wrapping
>+ * and the following to the implemetation's moz.build:

implemetation -> implementation
Attachment #8384346 - Flags: review?(mshal)
Attachment #8384346 - Flags: review?(mh+mozilla)
Attachment #8384346 - Flags: review?(gps)
Attachment #8384346 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/7d223c2e7fa9
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.