[install] There is no uninstall target created by CMake

[FreddieOliveira]

I'm upgrading from v1.3.1 to v1.4.0 in my Ubuntu 16.04 and I want to do a clean install. So I entered the v.1.3.1 folder that I had previously compiled and generated the Makefile and ran make uninstall but the rule uninstall doesn't exist. Is there an easy way to uninstall it that doesn't involve searching and deleting all files manually from my system?

[xor-gate]

There is currently no uninstall target created with CMake. It has not been implemented but this is what they explain on the wiki: https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake

[FreddieOliveira]

Thank you

[Nightwalker-87]

@FreddieOliveira: What about make clean and delete the project folder afterwards? As far as I am aware of, currently no files are spread throughout the system in linux/unix environments apart from manual settings such as udev- or modprobe-rules. Please correct me if this is wrong.

What do others think about implementing an uninstall target?

[FreddieOliveira]

What about make clean and delete the project folder afterwards?

Deleting the build directory would only purge the files inside it, leaving the ones added by the make install still hanging around on my system.

As far as I am aware of, currently no files are spread throughout the system

Version 1.3.1 was released February 2017 whereas version 1.4 was released in July that year. There's no way I would remember exactly which files were added to my system when make install was issued 5 months earlier. I didn't know by that time the Cmake creates a file called install_manifest.txt which lists all files added to your system, so in my mind the only solution was to run the make install again and check its output, or to use find.

Although the @xor-gate solution ( xargs rm < install_manifest.txt) works flawless, it'd still be nice to have an uninstall target.

[Nightwalker-87]

I think this has changed over time. make install does no longer seem to work in newer versions.
make [+target] does the job by now. Thus I can't verify this on my build system.
I may try out older versions someday, but that does require local fixes as they do not compile natively. We likely need others to assist with this.

[FreddieOliveira]

This issue is still present in recent releases. To reproduce follow the compiling manual. Basically:

1. Clone the repository: git clone https://github.com/texane/stlink && cd stlink
2. Now you can:
   • Compile with the default Makefile: make [Release|Debug]
   • This will create a folder called build/(Release|Debug) with the compiled files inside, as well as another newly created Makefile: cd build/(Release|Debug)
     OR
   • Manually create the build dir: mkdir -p build/(Release|Debug) && cd build/(Release|Debug)
   • Generate the Makefile: cmake -DCMAKE_BUILD_TYPE=(Release|Debug) ../..
   • Finally compile: make
     Both methods works exactly the same. Actually the first one is just a shortcut for the second.
3. Now, the newly created Makefile has the install rule: make install
4. After installing, a file called install_manifest.txt will be created. Check the installed files into your system by: cat install_manifest.txt

This is the output:

$ cat install_manifest.txt
/usr/local/lib/libstlink.so.1.6.0
/usr/local/lib/libstlink.so.1
/usr/local/lib/libstlink.so
/usr/local/lib/libstlink.a
/usr/local/bin/st-flash
/usr/local/bin/st-info
/usr/local/bin/st-util
/usr/local/lib/pkgconfig/stlink.pc
/usr/local/include/stlink.h
/usr/local/include/stm32.h
/usr/local/include/stlink/version.h
/usr/local/include/stlink/backend.h
/usr/local/include/stlink/chipid.h
/usr/local/include/stlink/commands.h
/usr/local/include/stlink/flash_loader.h
/usr/local/include/stlink/logging.h
/usr/local/include/stlink/mmap.h
/usr/local/include/stlink/reg.h
/usr/local/include/stlink/sg.h
/usr/local/include/stlink/usb.h
/usr/local/share/man/man1/st-util.1
/usr/local/share/man/man1/st-flash.1
/usr/local/share/man/man1/st-info.1

Despite providing an install method, the Makefile doesn't offer an unistall one. So, to manually uninstall it from the system you have to delete these files: xargs rm < install_manifest.txt

[Nightwalker-87]

Ah I see, but never did anything else than a simple make and then exported the build-directory path to $PATH via a terminal command. So far this worked just fine and avoided what you describe.

[FreddieOliveira]

As I said, the xargs rm < install_manifest.txt works just fine, as well using your strategy of exporting the $PATH, or even just creating a symlink to the binaries. But if it's not too much trouble an uninstall method would be nice. I don't understand how cmake works, so I have no idea how difficult it would be to implement this solution: https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake

[Nightwalker-87]

@FreddieOliveira: You may try that as well as a workaround until this is properly addressed. Taking note of this, I agree that if somebody closely follows all steps of the instruction (as you did), one would run into this problem. By the time implemented this was clearly not thought to the end. :-/

[Nightwalker-87]

Let's see, if we can solve this in the next release...

[Nightwalker-87]

@FreddieOliveira: Can you test if this works correctly?

[FreddieOliveira]

Hmm, still make: *** No rule to make target 'uninstall'. Stop.

I silenced the make output to fit the screenshot, but it ran correctly. The Makefile generated under the build dir still has no uninstall target 🙁

[Nightwalker-87]

Well these are two things: We have cmake and make, and this request was about to add an uninstall target for the former. However I have something to fix related to make as well, so I can have a look.

[Nightwalker-87]

This may be related to #804.

[FreddieOliveira]

But I don't get it, https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake suggests modifying CMakeLists.txt and creating a new file make_uninstall.cmake.in, but none of these changes were made.

I took my time however to contribute helping you guys with this pull request: #907

[Nightwalker-87]

No! I did implement that - look at the referenced commit (17 hours ago) just before I asked you to test. This targeted that commit of course. You seem to have tried with an older commit.
Now you have created a duplicate of that.

[FreddieOliveira]

Ooh, now I see. This was pushed into the ext_pkg_versions branch, I was testing with the master. My bad.

Indeed it fixes, thanks. Closing the issue as well as the duplicated PR. Just to know, when you intend to merge this into the master branch?

[Nightwalker-87]

Good, so it's not related to #804 then.

Yes, it will merge into the next release v1.6.1. You can track the related milestone. It's description should provide you with all info there is so far, including the release date (may be subject to change though, depending on progress). It is updated regularly so you should not worry to miss anything.

If you want to keep track with current changes and fixes, please stay on the develop branch.

[Nightwalker-87]

Fixed in commit e7ed76b.