emake should respect prefix like econf does, eg. make DESTDIR="${D}" install prefix=${EPREFIX}/usr instead of just make DESTDIR="${D}" install See https://www.gnu.org/software/make/manual/make.html#Directory-Variables make can be run with a prefix too, this is especially important for software not using autoconf but bringing a Makefile with it. Reproducible: Always
1. Support for custom build systems is not a goal. 2. There are makefiles where prefix needs to include DESTDIR, so this would break them.
>1. Support for custom build systems is not a goal. This is not custom, but standard makefiles as recommended by GNU make. >2. There are makefiles where prefix needs to include DESTDIR, so this would break them. THIS is custom and not the expected behaviour of makefiles!
(In reply to Simon from comment #2) > >1. Support for custom build systems is not a goal. > This is not custom, but standard makefiles as recommended by GNU make. Still, not going to happen. For the majority of build systems, the directory variables are assigned with configure. Assigning them again with make install would also mean that the ebuild has to override them twice if they have a value other than the default. Since you quote the GNU documentation, it also says: "Each GNU distribution should come with a shell script named configure." https://www.gnu.org/prep/standards/html_node/Configuration.html#Configuration
>Assigning them again with make install would also mean that the ebuild has to override them twice if they have a value other than the default. I'd then recommend a variable (eg PREFIX) for the prefix in ebuilds, that would also unify such cases where ebuilds need to overwrite the default prefix. Because prefix is also done different eg with cmake than with autotools, therefore having variable like PREFIX in an ebuild setting the dir and let portage manage how to configure that would be sensible and unify ebuilds.
This is getting insane. We won't be adding significant complexity to account for one package with another upstream who believes to be competent enough to write a useful build system and fails. We can consider this for next EAPI if you: A. Provide a reasonable proof that a fair number of packages benefits from it. B. Prove that it doesn't surprisingly break existing packages, or that the benefits outweigh the damage. C. Find a reasonable way to implement it, including reliable solution for ebuilds redefining src_install().
> A. Provide a reasonable proof that a fair number of packages benefits from > it. qgrep "emake prefix=" | wc 97 lines and lots of these lines are emake prefix="${ED}/usr" install therefore could be reduced to default by my approach. also qgrep "CMAKE_INSTALL_PREFIX" | wc 133 lines unifying these settings would therefore make sense i think. > C. Find a reasonable way to implement it, including reliable solution for > ebuilds redefining src_install(). one could set ': ${PREFIX:="$ED"/usr}' in src_configure and execution of default econf should "unset PREFIX" e.g.: src_configure() { : ${PREFIX:="$ED"/usr} if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then econf --prefix='${PREFIX}' unset PREFIX fi } and then emake could only set "prefix=${PREFIX}" if [ -n "${PREFIX}" ] cmake-utils.eclass would be implemented analogue to use the PREFIX-variable. > B. Prove that it doesn't surprisingly break existing packages, or that the > benefits outweigh the damage. with EAPI-change that shouldnt happen, also PREFIX is only given to emake if econf is not executed, one could also make the check for the PREFIX within src_compile / src_install then PREFIX is not applied with custom src_install.
Ah wait i confused ED and EPREFIX, but i think most of my arguments still apply conceptual.
(In reply to Simon from comment #6) > qgrep "emake prefix=" | wc > 97 lines That's a very small number, given that there are almost 40000 ebuilds in the tree. > and lots of these lines are > emake prefix="${ED}/usr" install > therefore could be reduced to default by my approach. Looking at a few of them, there are about as many prefix=${ED}/usr as prefix=${EPREFIX}/usr, and there are also prefix=/usr and prefix=${D}/usr. And didn't you have DESTDIR in your original request? Because some ebuilds pass DESTDIR but others don't. All in all, I don't see a regular pattern there. So the above would be usable by a fraction of ebuilds at the per mille level only, which doesn't justify making it a default.
> Looking at a few of them, there are about as many prefix=${ED}/usr as > prefix=${EPREFIX}/usr, and there are also prefix=/usr and prefix=${D}/usr. As far as i understand prefix=/usr and prefix=${EPREFIX}/usr can or even should be unified in the most cases. prefix=${ED}/usr and prefix=${D}/usr could then also be unified, but would have to be addressed differently anyway, the benefit of the variable would be to you just have to set PREFIX=${ED}/usr instead of parsing it to emake therefore you then dont need to have a seperate src_compile or src_install but just assign a variable, but: > And didn't you have DESTDIR in your original request? The DESTDIR should be default in makefiles if it isn't used the makefile has to be patched upstream. Then PREFIX=${ED}/usr isnt needed in most cases anymore, as that is only a workaround for missing DESTDIR in most cases.
