Status

defect
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: BenWa, Assigned: glandium)

Tracking

Trunk
mozilla28
x86
macOS
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

Currently we can't port gfx/test/gtest because we don't support UNIFIED_GTEST_SOURCES.
To see how we do this for WebIDL and IPDL generated code, see the usages of _add_unified_build_rules in python/mozbuild/mozbuild/backend/recursivemake.py.
webidl and ipdl are not the best examples.
Note i'm considering killing GTESTS_SOURCES shortly-ish.
(In reply to comment #2)
> webidl and ipdl are not the best examples.

Can you please add some information on how BenWa should attack this then?
(In reply to Mike Hommey [:glandium] from comment #3)
> Note i'm considering killing GTESTS_SOURCES shortly-ish.

Can you elaborate?
GTEST_SOURCES doesn't provide much added value over SOURCES, besides avoiding a check for MOZ_ENABLE_GTEST. And there are exactly three directories using GTEST_SOURCES. Sure there can be more in the future, but there's no reason the directory they're in can't be conditioned on MOZ_ENABLE_GTEST
even better... MOZ_ENABLE_GTEST is just a synonym for ENABLE_TESTS (considering what configure.in does)
(In reply to Mike Hommey [:glandium] from comment #7)
> even better... MOZ_ENABLE_GTEST is just a synonym for ENABLE_TESTS
> (considering what configure.in does)

Ohh well I was hoping we could keep GTEST_SOURCES and have them live along side normal sources instead of requiring a separate directory. Ideally moz.build would do away with this limitation. But if that's not planed then it's sound fine to me.

Yes ENABLE_TESTS should be enough.

However it may be worth considering compiling gtest sources after a normal build similarly to how we lazy link xul.
(In reply to Benoit Girard (:BenWa) from comment #8)
> (In reply to Mike Hommey [:glandium] from comment #7)
> > even better... MOZ_ENABLE_GTEST is just a synonym for ENABLE_TESTS
> > (considering what configure.in does)
> 
> Ohh well I was hoping we could keep GTEST_SOURCES and have them live along
> side normal sources instead of requiring a separate directory.

That's currently not possible anyways, because of how things are built. You'd always end up with gtest stuff in the normal libxul.

> Ideally moz.build would do away with this limitation. But if that's not planed then
> it's sound fine to me.

It is, but not quite right now.

> Yes ENABLE_TESTS should be enough.
> 
> However it may be worth considering compiling gtest sources after a normal
> build similarly to how we lazy link xul.

We're not lazy compiling currently. That will change in due time, but let's not worry about this now. So, I'll just kill GTEST_SOURCES now.
Summary: Add support for UNIFIED_GTEST_SOURCES → Kill GTEST_SOURCES
Posted patch Kill GTEST_SOURCES (obsolete) — Splinter Review
Attachment #8336724 - Flags: review?(gps)
Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
Posted patch Kill GTEST_SOURCES (obsolete) — Splinter Review
Forgot to cleanup config/rules.mk and configure.in.
Attachment #8336725 - Flags: review?(gps)
Attachment #8336724 - Attachment is obsolete: true
Attachment #8336724 - Flags: review?(gps)
With the python tests updated.
Attachment #8336746 - Flags: review?(gps)
Attachment #8336725 - Attachment is obsolete: true
Attachment #8336725 - Flags: review?(gps)
Attachment #8336746 - Flags: review?(gps) → review+
https://hg.mozilla.org/mozilla-central/rev/07884241d31f
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.