Closed Bug 1112236 Opened 10 years ago Closed 10 years ago

Unable to build unit test more than once

Categories

(Firefox Build System :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rbarker, Unassigned)

References

Details

Attachments

(1 file)

The unit tests for WebRTC need to be build twice. Unfortunately the build fails on the first run of make -f client.mk. It will build successfully on the second run of make -f client.mk however the since a different name can not be specified for the second build of the uint tests, they are copied on top of each other in $(OBJ)/media/webrtc/signaling/test.
At the shared work week I talked to you briefly about this issue I was having. I have created a simple patch that recreates the problem I am seeing. Hopefully this is just user error and there is a way to get this to work.
Flags: needinfo?(mh+mozilla)
Blocks: 1101651
Oh, so that's what you were trying to do... Well, the core of the problem is using GeckoCppUnitTests with ../something paths. Those paths designate the resulting binaries, so yes, they end up overwriting the others. The build system doesn't support what you're trying to do at all, unfortunately. That said, your patch doesn't make anything different than what the current moz.build does. Is that really your intent, or did you just left that part off? (btw, you should create a common .mozbuild file included in both moz.builds) If that was the intent, why exactly do you need the same thing built twice? If not, what would be the difference between both?
Flags: needinfo?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #2) > Oh, so that's what you were trying to do... > > Well, the core of the problem is using GeckoCppUnitTests with ../something > paths. Those paths designate the resulting binaries, so yes, they end up > overwriting the others. The build system doesn't support what you're trying > to do at all, unfortunately. > > That said, your patch doesn't make anything different than what the current > moz.build does. Is that really your intent, or did you just left that part > off? (btw, you should create a common .mozbuild file included in both > moz.builds) If that was the intent, why exactly do you need the same thing > built twice? If not, what would be the difference between both? I left out the part that sets different flags for each pass and links against different libraries for simplicity. Our problem is that we are trying to use a standalone XPCOM library to enable a standalone WebRTC library. Unfortunately the standalone library is missing a few features tested for in the current WebRTC unit tests. In order to land the standalone WebRTC library we need to run the unit tests twice, once with the original method of linking against XUL and again linked against the new standalone XPCOM library. I may have a different solution to pursue. Thanks for looking at this.
Here's how you can cheat for now: Create .cpp files in the again directory that #include "../filename.cpp", and use GeckoCppUnitTests(['filename'])
(In reply to Mike Hommey [:glandium] from comment #4) > Here's how you can cheat for now: > Create .cpp files in the again directory that #include "../filename.cpp", > and use GeckoCppUnitTests(['filename']) This suggestion appears to work. Thanks.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: