Commit generated XPM and PNG files

To remove build dependency on imagemagick ("convert" command) and to make life easier for people packaging and testing the plugin, we should commit generated files (storage is cheap) and version control them, so they are always ready to use.

As part of CI process we should verify that those files are always up to date.

we should verify that those files are always up to date

What is "up to date" for icons and how do we verify it after commit?

mentioned in merge request !3 (merged)

What is "up to date" for icons and how do we verify it after commit?

We just regenerate them again as part of CI. If it generates different files, build should fail.

But that requires adding imagemagick to CI. Also what's the point of storing icons if they are regenerated at every build? Am I missing something here?

Hmm, true. Is that an issue?

I'd suggest 'commit and forget': no generation in CI build. Why would icons change, especially XPMs?

If one changes the design of the icons, they must be re-generated then. CI should catch this kind of things, otherwise maintainer must check that manually.

They generally shouldn't change, I agree, but I think this is something which should be checked automatically.

I see. Well, I don't know how to convert XPM to PNG without convert or python's pillow or something like that. But as far as I understand there are no such tools in CI image.

Maybe conversion check could be done as a separate pipeline, only checking that, using different Docker image?

Rather than committing generated files into the VCS, the common workflow for autotools is to include them in generated dist tarballs.

After 75e8add8 we need to make Python optional in dist tarballs.

Xfwm4 (another package with themes) committed png and xpm files. Although they don't generate them as far as I understand.

mentioned in merge request !80 (merged)

For the record:

• plugin doesn't depend on imagemagick since e8ab1199
• build from release tarball doesn't require Python since 962895d7.