Define rules for extracting -dev packages

[treeswift]

We don't want to deploy headers and static libraries to the target unless we want to allow building dependent packages on the target, and that's what most users won't likely want to do. For the rest of the world, development files would be a distraction.

We don't want to filter development files out completely (breaking otherwise functional packages in case some essential files accidentally get marked as "development only"). Release packages <package> and <package>-dev (dependent on <package>) will still represent the complete build footprint of src/<package>.mk.

A good initial rule of thumb could be to split off */include/* and */lib/* (initial asterisk to accommodate suites that install into their own prefix, such as Qt). We probably don't want to deploy test suites (*/tests/*, test-*.exe) by default either. Eventually, however, the rules will be populated on a case-by-case basis. I would propose a growing "zebralist" (i.e. a black-and-white list): later and more specific rules override earlier and more generic ones.

Example:

exclude */include/* 
exclude */lib/*
exclude */tests/*
include */tests/absolutely-essential-tests-some-app-needs-to-run-daily/*
include */lib/perl/*
exclude */lib/perl/test-only/*
# etc. etc. etc.

The list can be parsed by mxe.postbuild.sh or a separate tool/script returning 0 for a regular deployable file and 1 for a dev-only one.

[pahaze]

I think the zebralist idea would work nicely. As for tests, maybe they should go in a separate package (<package>-tests)? That way it's not extra files clogging up the bin directory.

[treeswift]

Then probably <package>-diag — not only for tests, but for any troubleshooting tools as well.