<br><br><div class="gmail_quote">On Thu, Sep 29, 2011 at 3:22 AM, Hendrik Sattler <span dir="ltr"><<a href="mailto:post@hendrik-sattler.de">post@hendrik-sattler.de</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
People tend to misunderstand the purpose of build systems like CMake and autotools. They try to make the detection bullet-proof and most likely fail. You can see that this is wrong by looking at those auto* setups that take ages to detect all possible header files and use an ifdef hell to handle that in the code, run lots of link and symbol-finding tests, and still fail on conditions that the author simple didn't consider or know.<br>
</blockquote><div><br>The problem is in real world situations the software developer often has virtually zero control over system administration issues on systems their users are working with, and when your trying to be very portable you have to spot and handle as many as possible of the wide variety of situations that exist in the wild. The decision on how much effort to put into working around the existing issues (or at the very least detecting them before putting all the time and resources into a full compilation) is determined by the goals of the project. Knowing that *all* situations can't be handled is not a reason (at least for some projects) to avoid handling as much as they can - they keep improving their handling when they run into new issues.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I prefer option 1. It's not CMake's duty to detect or paper over messed-up systems. That's the administrator's job!<br></blockquote></div><br>Except there are cases where a software developer has to do their best to make their program work with the system as it is. Spotting results that aren't valid libraries in configuration is a time saver under those conditions.<br>
<br>Couldn't CMake provide the means to let developers turn on testing mechanisms (just disable them by default)? A project could explicitly enable CMAKE_CHECK_SHARED_LIBRARY_LINKING if they wanted to run the tests, and projects who don't want it could ignore the issue and never know the difference. As long as CMake provided the core mechanism and hooks needed to perform the test and feed in options, each project could decide what to do from there.<br>
<br>Cheers,<br>CY<br>