[CMake] DESTDIR behaviour with different variable name

[Tomasz Grobelny]

On Thu, 14 Apr 2011 05:57:34 +0200, Michael Hertling <mhertling at online.de>
wrote:
> On 04/12/2011 04:36 PM, Tomasz Grobelny wrote:
>> Somewhat hackish (especially this \$\(firstword \$\(MAKEFILE_LIST\)\)
> 
> Hackish, ugly, non-portable and absolutely inadvisable. ;-)
> 
>> part). I've just come up with another solution (probably not less
>> hackish,
>> but simpler and working):
>> set(CMAKE_INSTALL_PREFIX "\$ENV{MYDESTDIR}")
> 
> That's not hackish, IMO, but even quite elegant, indeed. Nevertheless,
> 
What I'm concerned about is dependence on double evaluation. If one day
cmake developers decide that evaluation should be done differently and/or
different number of times this could break. But hopefully this will not
happen anytime soon.

> Here, $ENV{MYDESTDIR} will end up as the installation prefix in the
> config file, so another project that calls FIND_PACKAGE(f) to learn
> about libf.so's location would need to have MYDESTDIR defined in its
> environment. 
> (...)
> Regarding this and the already mentioned issues in this respect, for
> what reason should one bank on an installation prefix evaluated at
> installation time? Just because the users are accustomed to "make
> install MYDESTDIR=..."? As I said before, I think that this is
> worth neither the effort nor the limitations nor the risks.
> 
Users are used to typing "make install" and currently MYDESTDIR is taken
from environment in Makefiles.
There are several factors that make this solution viable in my case:
 - whole product is built internally in tightly controlled environment. I
mean: no one will try to build or even use the library outside our internal
servers. Before the build of the product environment is set up using a
shell script. On the other hand "tightly controlled" does not mean I (as
developer) can change anything in our build system. Even if I would like to
do it the correct way.
 - currently we "suffer" consequences of installation time defined
installation directory. So moving to cmake will not change that in any way.
 - currently we can have several builds and we switch between them using
environment variables. Both for build and for simple use.

I hope I understand the risks. And if I shoot myself in the foot, well...
that's called experience :-)
-- 
Regards,
Tomasz Grobelny