On 12.03.2015 16:24, Tobias Hunger wrote:

A list of *all* headers used during the building of the target would
be fine. There is no need to filter that list down in any way.

CMake has that information: Without it cmake could not possibly know
when a cpp file needs rebuilding. It would not be as successful a
build system when it did not know that:-)

Even cmake does not know all headers need for compilation, this is done
by the compiler providing the dependency files.

Overall, wouldn't it be better cmake could parse something like a QBS syntax?
Or is also QBS's description not complete enough for an IDE? Is it good enough
for QtCreator?

I don't think extending CMake's language until eternity is a good idea,
the way should go away from it to a common scripting language, so that
generating meta-files becomes superfluous.


Also we don't really have information about where to put them. You can
use the minimum common denominator among the sources I guess.

I don't understand that part, sorry.


        }
    ],
    "installed" : "true",

I guess this means "make install" will install it. Where will this file end up?
Yes. I tried to figure it out but didn't manage to find the correct
way to query it. I can try harder. :D


    "name" : "LLVMPowerPCInfo",
    "output_directory" : 
"/home/kde-devel/tmp/llvm/build/lib/Target/PowerPC/TargetInfo",

For what is the output directory relevant? The output above does
implicitly list that already, doesn't it?
It's important in case the output path is overriden, see last e-mail
by Alexander Neundorf.


    "type" : "STATIC_LIBRARY"

Which types are possible here?
It's an enum internal to cmake. At the moment:
EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY,
OBJECT_LIBRARY, UTILITY, GLOBAL_TARGET, INTERFACE_LIBRARY,
UNKNOWN_LIBRARY.


},


There is a lot of useful information here! Thanks for pushing into
this direction. I am sure this will help a lot.

Ideally this file would be enough to provide all information we need
as an IDE to:

* Present the project structure as seen by the build system.
* Generate the code model
* Build the project
* Deploy the project
* Run and debug parts of the project
* Adding and removing files to a project

For the project structure this does help: It provides us with a list
of all the build targets, which is already nice. CMake does support
more structure with Projects and subprojects IIRC and that information
is lost. Would it be much work to get that information back?
as discussed above, I'll look into that next thing.

I am a cmake noob, but maybe I can help?

For the code model this is not much help at all: There is no
information on compiler used, include directories nor Defines or
compiler flags. Where am I supposed to get that information from? Do I
need to generate and parse the list of commands run and extract that
information from there? Having that information available right in the
sources array of each target would be so much more convenient and
would also make IDE integration so much easier: You would need to know
about one file only and won't need to figure out several.
We can do that, I mentioned earlier in this thread that currently
we're using compile_commands.json for that (
CMAKE_EXPORT_COMPILE_COMMANDS).

I agree it could be interesting to add it. In other words, if nobody
disagrees, I'll add it although I see how this will make the output
grow a lot.

I found parsing of compiler commands non-trivial: It gets messy when
some file gets built twice, especially when different defines, etc.
are set at the different times. E.g. once it is built with
-DENABLE_TEST by some unit test and once it is built without any flags
by the normal application.

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

Reply via email to