Clean target for SPKs

[Diaoul]

I don't know what the current behavior of PLIST for SPK is but I wish I did not have to "install" some stuff like here :
https://github.com/SynoCommunity/spksrc/blob/master/spk/umurmur/Makefile#L29

Would that be possible to have a file with this kind of structure for installing stuff in src/ ?

dir:var/
file:src/cert.fields:var/cert.fields
bin:src/umurmur.cgi.pl:share/synoman/umurmur.cgi

First part also defines the mode of the created file

[zebulon501]

The PLIST files define what to extract from the install directory (populated by the "make install" rules and like) to the staging directory (which will be copied to the target). The PLIST file of an SPK is useless, as SPK have no way to put files in the install directory. I think we should get ride of this file.

But I'm not convinced by a config file doing the same work as these install targets in the SPK: it would be a custom syntax, be more limited that what can be done using directly make, and add yet on more file where to look to know what is happening when you build an SPK.

I leave this open if you have more arguments.

[Diaoul]

Not the same thing exactly but another use case for such a file:
The goal is to get rid of some bins when you don't need them.
For example, umurmur doesn't need polarssl's bins. Yet, polarssl's PLIST has to include them as they could be used by another SPK.

Kind of a clean-up / select what you want file for SPKs instead of doing the clean-up in the post-install target

[zebulon501]

So we might need a specific target to do the clean up.

[Diaoul]

Maybe something like this in the Makefile of the SPK would define things to keep : https://github.com/Diaoul/syno-packager/blob/master/umurmur.mk

I'll implement this in a target I think, because a lot of stuff is not needed in SPKs. Mostly in bin/

[zebulon501]

Make this keep / clean target optional, like most of the other targets are.

And maybe a few unneeded files in the SPK are not that annoying. Most of the utilities built along with a library are simple front ends with not that much code, linking against the shared object.

[Dr-Bean]

This is mostly covered by using BUILD_DEPENDS instead of DEPENDS.