<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-07-17 22:54 GMT+02:00 Alfred Sawaya <span dir="ltr"><<a href="mailto:alfred@huji.fr" target="_blank">alfred@huji.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello folks,<div><br></div><div>I am trying to create a package with CPack from an External Project using the autotools. The make install part try to copy files to /usr/local/lib, but I do not want to package as root, so it fails. The cpack works because (I think) it create a temp dir and set it as environment variable before issuing the make install. </div></div></blockquote><div><br></div><div>Yes it does, in fact some CPack generator automatically set the DESTDIR var in order to tolerate files installed with absolute path.</div><div>This is the case (at least) of RPM and DEB generator.</div><div><br></div><div>In fact in your case if you try e.g. ZIP generator with</div><div><br></div><div>cpack -G ZIP </div><div><br></div><div>it will fail as with "make package".</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>But if I do a "make package", then it fails with permissions denied.</div></div></blockquote><div><br></div><div>Yep.</div><div>Because the pre-install target required by cpack does not use DESTDIR mechanism and thus uses the default prefix from /configure which is probably /usr/local</div><div><br></div><div>Note that the very simple "make" which tries to BUILD and INSTALL the external project fails as well because it wants to install is /usr/local.</div><div><br></div><div><div>e.g. note that with your current setup if you do:</div><div>DESTDIR=/tmp make package<br></div><div><br></div><div>you get what you want in the DEB file.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I am not the first to get stuck with this issue (<a href="https://stackoverflow.com/questions/44724281/cpack-building-external-autogen-project-with-bad-output-location" target="_blank">https://stackoverflow.com/<wbr>questions/44724281/cpack-<wbr>building-external-autogen-<wbr>project-with-bad-output-<wbr>location</a>)</div><div>So I do not think that there is a direct solution ? Anyway, I can implement one and send the patch. </div><div><br></div><div>I see only one solution to this issue: actually set a prefix on the external project and implement a boolean variable CPACK_IGNORE_INSTALL_PREFIX to remove it into the package. I tihnk it is the most consistent way to resolve this ?</div></div></blockquote><div><br></div><div>I would say you should find a way to have 2 differents prefixes.</div><div><br></div><div>The first should be used when doing "make"</div><div>The second one used when cpack runs.</div><div><br></div><div>All that said, may be you can "simply" craft an install_command script you can call in the</div><div>INSTALL_COMMAND argument of ExternalProject_Add and which verifies if DESTDIR is already set or not</div><div>in order to call "make install" or "DESTDIR=/choose/your/path make install".</div><div><br></div><div>However this is kind of workaround to throw away the first install step done when doing make while</div><div>keeping the second one done by cpack...</div><div><br></div><div>Which makes me think, if you primary goal is to package an external project, wouldn't it be simpler to add support for a "PACKAGE" step to </div><div>ExternalProject ? Or is this external project meant to be packaged in the same package as the project using it?</div><div><br></div><div><br></div><div>--</div><div>Eric</div><div><br></div></div>
</div></div>