1112236 - Unable to build unit test more than once

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Randall Barker [:rbarker]]

Attachment: Patch that recreates the problem.

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.

Comment 1

[Randall Barker [:rbarker]]

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.

Comment 2

[Mike Hommey [:glandium]]

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?

Comment 3

[Randall Barker [:rbarker]]

(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.

Comment 4

[Mike Hommey [:glandium]]

Here's how you can cheat for now:
Create .cpp files in the again directory that #include "../filename.cpp", and use GeckoCppUnitTests(['filename'])

Comment 5

[Randall Barker [:rbarker]]

(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.