Hi Gerhard, > Minor make nit: Was to understand that $(RM) is more portable, > and might be preferred. But could not find examples in existing > rules within the minute that I spent searching. It's pre-set in > GNU make, can't speak with certainty for automake on other > platforms that don't use GNU make.
I was wondering about that, too. I used 'rm' for consistency. > This subject might be a sensitive one. Will users get angry when > *all* directory content gets removed, including the files that > were added by other means than libsigrokdecode installation? Valid point. > When the install script gets extended to optionally remove > decoders: Will users be surprised if _some_ of the content > remains, when the source has changed between installation and > uninstallation and thus won't remove what got installed before? > (This may be the situation that you faced.) Exactly. I agree this is my "fault" if I run install and uninstall with a different source base. But I still wondered that there was no removal at all... > Either choice of broad or fine selection what to remove could be > as wrong as any other one might come up with. The most reliable > option is to "somehow install" the files _and_ track what got > installed, to remove that very installed content (and maybe only > if it wasn't modified after installation -- the change may have > been expensive and worth keeping). This is probably beyond a mere > make rule. Touches policy, and is what package managers do and > are good at. ... because I thought that is good practice to remove what you installed. Actually, I thought it was a requirement. However, I have no idea where the border between Make rules and package management is. > If you ask me, I'd add another "data uninstall" target for > symmetry, and add a -u option to the Python install helper script > to uninstall those files which ship with the sources. This would > work for packagers, and developers when sticking with one version > or similar content across versions. Doesn't cover your specific > use case, and neither prevents the loss of local manipulation > after installation. So it combines all disadvantages of either > approach. Must be acceptable as everyone gets just a little > unhappy. :-P Heh, yeah. It wouldn't solve the case I was experiencing, but this is not so important because of "my fault". Cleaning up these files should still be good, I think. While your sketch looks very reasonable, it is beyond what I want to dedicate to this issue. > As long as automatic support for most appropriate removal is > missing, it's probably most robust (and needed rarely enough) > when those who install from source just go to the directory they > install to (it's likely to be something isolated and local > specific), and decide when to remove and what to remove. Lets > them keep what's important to them, and can be as simple as just > removing the single directory, or can selectively remove a few > decoders which became obsolete. Yes, unless a proper solution is implemented, we should rather keep than mindlessly delete. However, a FIXME comment in Makefile.am might be good to have? Thanks for the comments, Wolfram
signature.asc
Description: PGP signature
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
