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 <neund...@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
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
