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.
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 ofsrc/<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:
The list can be parsed by
mxe.postbuild.shor a separate tool/script returning 0 for a regular deployable file and 1 for a dev-only one.