On 31/03/14 15:55, Werner LEMBERG wrote: > >> 1) DESTDIR is fundamentally broken, for installations on MS-Windows >> hosts; not a big deal, I guess, provided the user performing the >> installation task is aware that they cannot use it. > > Interesting. I haven't used DESTDIR by myself, but I got requests to > implement that for virtually everything. Do you have a link > explaining the reasons?
Well, you are welcome to trawl the archives of the MinGW-Users and MinGW-Dvlpr mailing lists; IIRC, I may also have discussed the issue, briefly, with Ralf Wildenhues, on the Autoconf list. Alternatively, you may wish to accept the following explanation: 1) The usage for DESTDIR, as stipulated in the GNU Coding Standards, is in the form of references, in makefiles, such as $(DESTDIR)$(prefix)/some/installation/path $(DESTDIR)$(exec_prefix)/some/installation/path 2) The GCS forbids any makefile to define DESTDIR; that is exclusively the prerogative of the user, when invoking make. 3) Both $(prefix) and $(exec_prefix), (which are often coincident), *must* be defined as *absolute* paths; thus, on MS-Windows hosts, they take the form prefix = D:/installation/root exec_prefix = D:/installation/root (where D: represents an arbitrary, but necessary, device identifier). 4) The user specifies DESTDIR, at "make install" time, e.g. make install DESTDIR=staging/dir On MS-Windows hosts, this results in *unconditionally* malformed paths, in the form staging/dirD:/installation/root/some/installation/path which is invalid; it can only ever be valid, if DESTDIR remains unspecified. >> 2) Does DESTDIR have any real value, for an uninstall target? > > IMHO yes. It's good for testing purposes. In the days before the GNU Standards Committee were persuaded to adopt DESTDIR, the prescribed technique was to configure prefix, (and maybe also exec_prefix), to point to a testing sandbox: ./configure --prefix=/path/to/sandbox ... or to override them at "make install" time: make install prefix=/path/to/sandbox exec_prefix=/path/to/sandbox This technique remains as viable today, as it always was, and it does not require DESTDIR; it also has the advantage of working on MS-Windows hosts, where DESTDIR is guaranteed to fail. >> Its value lies in staging binary packages; "rm -rf ..." is the >> simplest way to clear a staging tree, (unless multiple packages are >> staged in a common tree, perhaps, and only one is to be selectively >> discarded). > > Well, `make install' should be the opposite of `make uninstall' > *without moving stuff*. It's an assymetry if installing with DESTDIR > works, but uninstall doesn't. Agreed, but it is an imposition on the user, to ensure that DESTDIR is defined identically when invoking: make install DESTDIR=/path/to/sandbox and subsequently: make uninstall DESTDIR=/path/to/sandbox (Of course, the same is true of overriding prefix and/or exec_prefix at "make install" time; the only way to completely avoid this issue is to specify the /path/to/sandbox at "configure" time). >> The concern is that DESTDIR is not preserved between install and >> uninstall, placing an onus on the user to specify it identically on >> both occasions. > > AFAIK, the DESTDIR stuff is to build a package for a distribution; > there are other means to install and uninstall packages. So moving > isn't a concern IMHO. Oh, I'm well aware of the arguments in favour of DESTDIR; I just don't buy them. In reality, DESTDIR is a universally broken concept, IMHO. It acquires value, only for distributors who create perversely arcane installation structures, with the likes of $(docdir), for example, relocated outside of the $(prefix) and/or $(exec_prefix) trees. -- Regards, Keith.
