<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-03-23 11:44 GMT+01:00 Mario Emmenlauer <span dir="ltr"><<a href="mailto:mario@emmenlauer.de" target="_blank">mario@emmenlauer.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Eric,<br>
<br>
On 23.03.2018 10:58, Eric Noulard wrote:<br>
> 2018-03-23 10:21 GMT+01:00 Mario Emmenlauer <<a href="mailto:mario@emmenlauer.de">mario@emmenlauer.de</a> <mailto:<a href="mailto:mario@emmenlauer.de">mario@emmenlauer.de</a>>>:<br>
<span class="">><br>
><br>
>     Thanks PF, I think this makes more sense now! I was assuming that<br>
>     cmake always prefers CMAKE_PREFIX_PATH over builtin paths. But as you<br>
>     clarified, that only applies to libraries that provide find_package<br>
>     support.<br>
><br>
>     This is actually quite unfortunate. Then I don't see an easy way to<br>
>     enforce usage of specific libs. As an example, if I want to enforce a<br>
>     patched libtiff (that does not itself provide find_package support)<br>
>     the only "safe" way is to replace the system libtiff. Otherwise any<br>
>     package might just find the system version first without me even<br>
>     knowing.<br>
><br>
><br>
> You can always ship your own/patched version of  Find<Whatever>.cmake module with your<br>
> project source and build the 'local' override logic in it for every project/lib that does not provide a find_package.<br>
><br>
> Be sure to APPEND your local cmake module path (CMAKE_MODULE_PATH)<br>
><br>
> something like:<br>
>  list(APPEND CMAKE_MODULE_PATH ${AFS_SOURCE_DIR}/cmake)<br>
><br>
> before using find_package etc...<br>
><br>
> I find it a "safer" solution than system lib replacement.<br>
> My opinion though.<br>
<br>
</span>I was considering this option too. But in my original email I outlined<br>
that this is not only for my own package, but additionally for more than<br>
30 thirdparty dependencies. So its not only about ensuring that my<br>
packages use the correct thirdparty version, furthermore the packages<br>
themselves have inter-dependencies that must be correctly resolved.<br></blockquote><div><br></div><div>Sorry I missed that part on third party.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I'd need to ship my own FindZLIB, FindTIFF, FindPNG, FindJPEG, FindPROJ4,<br>
FindHDF5, FindFFTW, ... etcetc, and override the ones of all my thirdparty<br>
dependencies. It would create a maintenance hell :-(<br></blockquote><div><br></div><div>Yep I can perfectly imagine.</div><div>I know well a project for which we do exactly that.</div><div><br></div><div>1) Collect all third party sources for which we want to control precise version (and/or need a patch)</div><div>2) Configure, compile and install them all on a private dir</div><div>3) Configure and  build my project using those installed 3rd party libs. </div><div> </div><div>this is the only way we can find to have "clean" multi-linux-distrib' support.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How are other people resolving this?<br></blockquote><div><br></div><div>I'm interesting in this as well, but as soon as a 3rd party is using something you use</div><div>you end-up putting your hand in third party or override system lib (which is not an option for us). </div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div>
</div></div>