search

pupnp / pupnp

libupnp: Build UPnP-compliant control points, devices, and bridges on several operating systems.
https://pupnp.github.io/pupnp
BSD 3-Clause "New" or "Revised" License
352 stars 117 forks source link

No uninstall available with CMake Build #319

Closed ingo-h closed 3 years ago

ingo-h commented 3 years ago

According to the README - 11.2. Uninstall this can be done with

% make uninstall

But this is not available when using a 10.7. CMake Build:

pupnp-build$ sudo make uninstall
make: *** No rule to make target 'uninstall'.  Stop.
Vollstrecker commented 3 years ago

That's right it should be pointed out clearly that this only applies for autotools. cmake intentionally doesn't provide uninstall-target. On unix you could do xargs rm < install_manifest.txt I'll leave it open for discussion if I should create one, as CPack is on my ToDo I don't see really a need for this. Usually I don't expect users to install selfcompiled software into dirs that are used by the usual system-libs.

ingo-h commented 3 years ago

Where to find install_manifest.txt?

mrjimenez commented 3 years ago

Doesn't the existence of install_manifest.txt imply that a Makefile has been created?

Vollstrecker commented 3 years ago

Where to find install_manifest.txt?

In the build-dir

Doesn't the existence of install_manifest.txt imply that a Makefile has been created?

Doesn't installation imply that a Makefile has been created?

mrjimenez commented 3 years ago

Doesn't the existence of install_manifest.txt imply that a Makefile has been created?

Doesn't installation imply that a Makefile has been created?

Sorry, I am not used to Makefiles out of the sources dir. Now I see what cmake did, it created lots os Makefiles in the build directory and its subdirectories. Very odd, but easy to remove.

Having an uninstall target seems reasonable to me, why do the cmake guys think it is so ugly? I think it is a good thing to have.

Vollstrecker commented 3 years ago

Yeah, that cluttering of files is the best reason for building outside the source-dir. Beside the fact that Makefiles always represent only one config. I really enjoy to just change dir to switch e.g. from debug to release builds. But with the many files you have some additional comfort. You can in the toplevel just do make ixml_shared to only build that (or anything listed in make help) which maybe is possible the old way, but the targets are not that easy to find out. And you can just to to upnp/ and type make and it will also work (including the build of ixml). And you won't have to list anything in .gitignore, as there goes nothing in the source that you didn't change yourself.

Having an uninstall target seems reasonable to me, why do the cmake guys think it is so ugly?

There are different reasons:

  1. They rely on the FHS. They expect the user to use /usr/local/ to install selfcompiled stuff without the system-package-management, there the can just do an rm, or on Win it all goes to it's own dir.
  2. They have an eye on all plattforms and created CPack. With that you can create .deb or .rpm the same way as an installer-binary for win. These also take care of uninstallation.
  3. It's hard to decide what finally can be removed. I added the components, so you can install only upnp dev files but both runtimes, does uninstall remove them all, or just the last installed? And if you configure with different option in the time between install and uninstall, who takes care of the differences? In this case the user relies on the system and get's artifacts which doesn't happen if he just uses the packages or separated installation-dirs.

But if you like to have one, my patch-of-the-day can be that.

ingo-h commented 3 years ago

Where to find install_manifest.txt?

In the build-dir

pupnp$ git pull upstream master
pupnp$ rm -fr ../pupnp-build/
pupnp$ cmake -B ../pupnp-build .
pupnp$ cmake --build ../pupnp-build
pupnp$ find ../pupnp-build/ -iname "install_manifest.txt"
pupnp$

Why find does not find install_manifest.txt in the build-dir? What I'm doing wrong?

Vollstrecker commented 3 years ago 
~$git clone https://github.com/pupnp/pupnp.git
~$cmake -S pupnp/ -B pupnp-build
~$cmake --build pupnp-build/
~$DESTDIR=`pwd`/pupnp-inst cmake --install pupnp-build/
~$find pupnp-build/ -iname "install_manifest.txt"
pupnp-build/install_manifest.txt
~$

No installation, no manifest.

Vollstrecker commented 3 years ago

And don't try the xargs with higher privileges, as this doesn't honor DESTDIR and will delete your systems installation.

mrjimenez commented 3 years ago

But if you like to have one, my patch-of-the-day can be that.

If you are telling me that this is a non-issue for distros that use rpm or deb and that normal users should just install it under /usr/local/something and remove the folder, I can live with that.

Autotools used to take care of this, even in the /usr/loca case, because the supposed hierarchy is to install the binaries in /usr/local/bin, the includes in /usr/local/include, the libs in /usr/local/lib, etc, thus making it tedious to do it by hand.

Installing stuff inside /usr/local/something has the inconvenient that you would have to mess with the system paths, like PATH and LD_LIBRARY_PATH to have stuff working.

Vollstrecker commented 3 years ago

If you are telling me that this is a non-issue for distros that use rpm or deb and that normal users should just install it under /usr/local/something and remove the folder, I can live with that.

Live with the risk this target brings, or with missing the target?

Autotools used to take care of this, even in the /usr/loca case, because the supposed hierarchy is to install the binaries in /usr/local/bin, the includes in /usr/local/include, the libs in /usr/local/lib, etc, thus making it tedious to do it by hand.

cmake defaults also to /usr/local. includes go to /usr/local/include/upnp ,so that's easy to find. samples, pkg-config cmake-config and the libs are another topic. I didn't check, but iirc autotools have the same problem and can let the user run into it. What happens if you want to check something and install with DESTDIR=something and then make uninstall and forget the DESTDIR? And yes, I suppose uninstall would honor that,too.

Installing stuff inside /usr/local/something has the inconvenient that you would have to mess with the system paths, like PATH and LD_LIBRARY_PATH to have stuff working.

Sure, that's why I'm going to include CPack. For produktive usage it should be installed somewhere that doesn't need these things, but it should also be installed in a way that other packages from the system can use them, which only works if the packaghemanager knows about them, otherwise you would need to tweak these path's again to let the selfcompiled one be found first.

ePirat commented 3 years ago

IMO it is fine to not offer a uninstall target with CMake, as there is not really a very good risk-free way to do it, afaik.

mrjimenez commented 3 years ago

If you are telling me that this is a non-issue for distros that use rpm or deb and that normal users should just install it under /usr/local/something and remove the folder, I can live with that.

Live with the risk this target brings, or with missing the target?

Live without the target. In other words, I trust you.

Sure, that's why I'm going to include CPack. For produktive usage it should be installed somewhere that doesn't need these things, but it should also be installed in a way that other packages from the system can use them, which only works if the packaghemanager knows about them, otherwise you would need to tweak these path's again to let the selfcompiled one be found first.

Nice :+1:

So, we leave it with no uninstall target.