[cmake-developers] Proposal to teach cmDepends to only take dependencies from the source tree

[Attila Krasznahorkay]

Hi Alex,

I never claimed that this simple proposal could be good for everyone.

As far as I can see the main question is: If we implement an option in such a simple way (adding the binary dir to the search path as Ben very rightfully pointed out), would it be useful to a significant number of people? Or would we need to implement it in a more complicated way (possibly introducing a regular expression for selecting which include paths to include in the dependency generation) to make it useful for enough people?

I myself am on the side of simplicity. Using regular expressions would allow us to do what I want. But if >95% of the people using this new possibility would use it exactly like I plan to, then implementing it in a more complicated way than necessary would just be a bad design choice.

I'd leave the decision between these two possibility to you guys. I don't even want to argue that this should become the default behaviour in the future. I just argue that it should be possible to enable such a behaviour in some way if the user explicitly chooses to use it.

Cheers,
               Attila

> On 08 Dec 2015, at 21:46, Alexander Neundorf <neundorf at kde.org> wrote:
> 
> On Tuesday, December 08, 2015 11:14:07 Ben Boeckel wrote:
> > On Tue, Dec 08, 2015 at 10:09:13 +0100, Attila Krasznahorkay wrote:
> > > In the end I applied the following patch to CMake 3.4.1 locally to
> > > speed it up for my use case very significantly. Of course this is not
> > > a patch that could be applied to CMake for a general audience. But I
> > > do think that if this code/behaviour could be switched on using
> > > something like a directory property / global variable, a lot of users
> > > could make good use of it. As it can be a reasonable assumption in
> > > many development environments that only the changes inside of the
> > > source tree should be tracked by the build system.
> > 
> > So some projects allow you to override specific headers (e.g., Boost) to
> > provide <boost/config/user.hpp> which would be included from the source
> > tree. This file is not included directly by any users of Boost
> > (usually), but instead included via other Boost headers, so scanning of
> > system includes can be important.
> > 
> > So as long as there's an option/policy for it, I'm fine with the
> > behavior. A policy could make it the default too with a directory
> > property to re-enable global scanning.
> > 
> > Hmm…the build tree should also probably be allowed as well.
>  
> Yes.
> I think I have also seen projects where the "top level"-CMakeLists.txt is actually not at the root of the project, but in a subdir, e.g. cmake/.
> In that case all source files are outside ${CMAKE_SOURCE_DIR}.
>  
> Alex
>