542749 - SDK installation with --enable-tests installs test includes and idl

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

(Seeing the changes in toolkit/mozapps/installer/packager.mk, I guess the problem is the same on trunk)

A bunch of extra test includes and idl files get installed in prefix/include/appname-version and prefix/share/idl/appname-version when building with --enable-tests (which is the default).
Example of such files are nsISample.idl, xpctest.idl, TestHarness.h, etc.

Even worse, when building with --enable-javaxpcom (default in xulrunner builds), the corresponding java interfaces end being packed in MozillaInterfaces.jar.

I came up with a gross hack in config/rules.mk:
ifneq (,$(findstring sample,$(MODULE))$(findstring test,$(MODULE))$(findstring Test,$(MODULE)))
PUBLIC := $(DIST)/tests/include
IDL_DIR := $(DIST)/tests/idl
LOCAL_INCLUDES += -I$(XPIDL_GEN_DIR)
override MOZ_JAVAXPCOM :=
XPIDL_FLAGS += -I$(DIST)/idl
endif

This definitely is ugly, but is a good enough workaround for me. Anyways, the idea behind it is maybe a good one, though: having test includes and idl files installed somewhere else than $(DIST)/include and $(DIST)/idl.

Note this gross hack still leaves TestHarness.h around, I just remove it by hand afterwards.

Comment 1

[(not currently active) Ted Mielczarek]

We deal with this in application packaging by having a package manifest that explicitly lists things to package. Probably maintaining that list for the SDK would be overwhelming, but perhaps we could implement a blacklist of testing components instead? That way if we add one and forget to blacklist it, it's not all that bad, certainly not as bad as accidentally forgetting to whitelist useful platform files.

Comment 2

[Mike Hommey [:glandium]]

On 1.9.1, the prefix/include/unstable directory was flat, so all files were mixed (contrary to prefix/include/stable), but this is apparently gone in 1.9.2 and trunk, which means for includes at least, it is possible to make some distinctions. TestHarness.h, for example, is in include/testing. Basically, includes end up in $(DIST)/include/$(MODULE). If idl files were put in a similar way, it would be much easier to do a blacklist, or even better, maybe they should all go in the "testing" module.

Comment 3

[Chris Cooper [:coop] (he/him)]

Mass bug cleanup for Core:Build Config.

If you feel this bug has been closed in error, please re-open with new details.