TinyML Project Export: Reconcile Library Sources with Unspecialized Examples

A generated TFLM project contains the requested optimized library but still uses a generic example input provider. Another export run uses --no_copy yet changes files. Both observations follow from the project generator's separate handling of library sources, example sources and dependency preparation.

Treat the export as source selection for an external build system, not as a complete board project or an inherently read-only manifest command.

Follow the library manifest into the Makefile

The pinned project generator asks Make for library sources, library headers and third-party files using the supplied --makefile_options. Those returned paths determine the runtime portion of the exported tree.

The Makefile's list targets expose the selected runtime and kernel source lists after configuration. Its source-selection logic can replace base implementations with optimized, coprocessor or target-specific ones. Copying every source recursively from the repository is therefore not equivalent to compiling the export manifest.

For an unexpected duplicate implementation, compare the generated list with the external project's actual compiler inputs. Check whether the IDE imported an additional repository directory, retained a file from an earlier export or compiled both the base and selected versions. Resolve the source-list discrepancy before changing linker flags.

Examples deliberately use a different selection policy

The generator's _create_examples_tree does not pass the library's target and optimized-kernel options to its example-list queries. It deliberately exports an x86-oriented example view and leaves board-specific additions and removals to the downstream project.

Thus selecting a Cortex-M library does not automatically select the board's microphone or camera provider. Inspect the exported example files directly. A placeholder provider can coexist with a correctly selected runtime library; those two outcomes are not contradictory.

The new-platform guide likewise assigns peripheral integration to the platform project. It recommends providing platform logging, timing and setup implementations, then using a simple example before adding peripheral-specific behavior. The required development environment includes C++17 support, a board SDK and suitable compiler/linker configuration.

Do not interpret no_copy as a dry-run guarantee

In this script revision, --no_copy guards the main library/dependency copy call. Dependency preparation through third_party_downloads happens earlier regardless. If examples were requested with -e, their separate creation function still runs afterward and copies or rewrites example files.

The optional extension-renaming pass also runs independently. Therefore, use a dedicated export directory and a checkout where dependency preparation is acceptable. Do not invoke this combination against a valuable source tree expecting it to be side-effect-free. This article inspects the implementation; it did not execute the exporter.

The printed source/destination lists are produced from the main library/dependency selection before the separate example phase. They should not be treated as a complete inventory of every file the command can write.

Reconcile the final tree with the consuming project

Keep two concrete inventories: the exported runtime/dependency files and the example files actually included in the board build. Compare each with compiler inputs. For a missing header, check the exported directory and include root; for an unresolved provider, check the board-specific example implementation; for a duplicate implementation, check whether old and new source selections were combined.

The guide separates third-party dependencies so integrations can manage shared copies and avoid symbol collisions. Preserve that distinction in the external project rather than importing another uncontrolled dependency copy.

Finally, regenerate into a separate clean output directory when changing configuration and compare the result before replacing the integration. The exporter selects sources; the external project remains responsible for compiling that selection with the intended platform files. A successful export alone establishes neither a working sensor pipeline nor a validated firmware build.