On Wed, Apr 1, 2015 at 12:41 AM, Stephen Kelly <steve...@gmail.com> wrote:
> Anton Makeev wrote:
>
>> The problem with the following format:
>> ---
>> "include_directories" : ["/foo", "/opt"]
>> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"]
>> "compile_flags": [ "-c" ]
>> —
>> Is that it’s incomplete and cannot be used directly:
>> * include directories list misses compiler-defined search paths
>
> CMake gathers those during configure time, and we can add them to the
> metadata too.
That is not necessary for QtC. Feel free to add this information if
somebody else needs it.
<snip>
>> * compiler definition do not include compiler-defined(built-in)
>> definitions etc.
>
> CMake does not currently gather those during configure, as far as I know.
> That could be added though.
That is not necessary for QtC. Feel free to add this information if
somebody else needs it.
Creator will parse the compile_flags anyway, so it does not matter to
me whether some defines/includes end up being hidden in there, but I
would prefer to get as much of the information separately if possible.
So please keep the include_directories and compile_defines that cmake
knows about separate. That is so much nicer to parse than some command
line, especially when escaping starts to get necessary.
>> That is, to have the complete list of include directories and compiler
>> definitions, the IDE will have to call the compiler anyways. And here is
>> where it will need the actual compiler’s command line.
>>
>> Should we had the full list of include directories (split into groups
>> like: <>, quote, and frameworks) and the list of all compiler defines, we
>> would not need the compiler command-line at all.
We do need to know the compiler *binary* (/usr/bin/gcc), but not
necessarily the complete command line that is run ("/usr/bin/gcc -c
-Dsomething -I/some/path something.cpp something.o"). We do of course
need to be sure that we have all the information to generate that
command line in the form of compile_flags, compile_definitions,
include_directories and whichever other flags may be relevant.
<snip>
>> Though I don’t this it’s a
>> way to go for CMake generation, since the compiler should be called for
>> every unique command-line flags and undoubtedly make generation way
>> longer.
>
> It's not completely clear to me what you are suggesting here. Maybe you know
> something I don't know.
>
> Can you be clear about what you are suggesting CMake would have to do for
> each unique command line? I know you are not proposing that CMake should do
> it (you said the IDE should do it lazily instead), but what action are you
> actually talking about? What should the IDE do lazily instead of CMake doing
> it? Invoke the compiler to determine the compiler-defined/built-in include
> directories and definitions? They will always be the same, right? Or are you
> talking about the "-I-" GCC option here and how that clears the built-ins?
> Please be more specific.
If you want to log the compiler-defined defines into the Json file,
then cmake obviously needs to query the compiler for those.
These defines are heavily dependent on the command line flags you pass
(e.g. -std=c++11 will set some other defines than -std=c++98). There
is a long list of options that change the defines set by the compiler.
Some of these are actually defined in some standard, others seem to be
more like implementation details of the specific compilers used.
So that means cmake would need to run the compiler once for each
possible set of options passed to the compiler during the later build
steps, so that it can put this information into the meta-data file.
That seems a bit excessive to me, even though creator could probably
use that information if you did provide it. Currently our
projectmanagers just query for the compiler defines themselves. They
have to as currently none of the supported build system provides this
information.
Best Regards,
Tobias
--
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
