<div dir="ltr"> On Fri, Sep 5, 2008 at 10:13 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I disagree. The fact that FooConfig.cmake was loaded means that Foo<br>
*was* found. It is up to the module to report other information for<br>
consumption by the project. Perhaps the project finding Foo just wants<br>
to load some documentation files from it and doesn't care about its<br>
linking dependencies. For this reason the find_package command in<br>
Config mode defines "found" to mean that the module was found and<br>
loaded. It is going to set Foo_FOUND to true after loading<br>
FooConfig.cmake no matter what the module does (unless it has a syntax<br>
error). Setting it inside the module will have no effect (though the<br>
fatal error message will prevent the overall configuration from succeeding).</blockquote><div><br>Ok, thanks for this explaination. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I do not recommend searching for required dependencies inside<br>
"FooConfig.cmake". The process that put it there in the first place<br>
should have hard-coded inside it the locations of all dependencies. If<br>
it comes with a system package file (like a .deb), then that file should<br>
have a dependency on the boost package and know where it will be<br>
installed. If it comes from the user having built and installed Foo,<br>
then that build/install process should have found boost on the machine<br>
already. Using a different boost could lead to problems, so the<br>
location should be hard-coded.</blockquote><div><br>I agree that ideally the paths should be hardcoded. But it means that I must provide one devel package per target system. Unfortunately, I cannot do that for two reasons:<br>
- I do not have the infrastructure to compile and make package on many systems.<br>- I work with people that have the bad habit of installing software in non standard places. Some of them cannot be blamed because they have no admin privilege and must install missing software on their home directory.<br>
<br>This is why my foo-devel.tar.gz will be as system independant as possible by providing a FooConfig.cmake looking for depedencies and allowing users to specify non-standard places. In this case the config file has the responsability of checking that the packages found have compatible version and config (which can probably be difficult for software using add_definition and #if... directives).<br>
<br>Best regards,<br><br> Yann Cointepas<br><br></div></div><br><br>
</div>