On Do, 2016-06-09 at 08:43 -0400, Brad King wrote:
> On 06/09/2016 05:47 AM, Tobias Hunger wrote:
> > I made some progress with extracting project structure from cmake via the
> > daemon-mode. I am rather happy with the information and would love to get
> > some
> > feedback from other interested parties.
>
> For reference, some design work on a format like this was discussed
> in another thread a couple years ago:
>
> Extracting target metadata, IDE integration, 2014-09-19
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus
> =11000
I know, I partitcipated in that discussion.
> > # Data:
> > "projects":
>
> To what does each "projects" entry correspond?
This is basically a list of (sub)projects. They are not really ordered, but
since they all have a sourceDirectory that should not be a problem.
> > [
> > {
> > "configurations":
> > [
> > {
> > "name":"",
> > "targets":
>
> Should "configurations" be an array or a map? A map would guarantee at most
> one configuration of a given name.
An array is IMHO easier to handle. A hope cmake already guarantees that the
names of its configurations are unique, so I do not think this is an issue one
way or another.
> > [
> > {
> > "fullName":"test",
> > "name":"test",
> > "type":"GLOBAL_TARGET"
>
> I've never liked the name "GLOBAL_TARGET" because it does not really represent
> what the type of target is. I think we should avoid exposing the internal
> enum
> names through the protocol (we already do in the TYPE target property, but the
> GLOBAL_TARGET type is never available there). Unfortunately I've never come
> up with a better name, so I'd welcome suggestions. The target type is used
> for
> CMake-generated targets that get separately generated in each build
> (sub)directory,
> like "make install" and "make test". Their effects are localized to each
> directory
> in generators that support that.
I am using the output of cmState::GetTargetTypeName. I do not want to map those
names to something else if I can avoid it:-)
> > },
> > # <snip>
> > {
> > "buildDirectory":"/tmp/cmake-build-
> > test/Source/CursesDialog/form",
> > "fullName":"libcmForm.a",
>
> The build directory and the location of the library file may not be the same.
> Also, there may be more than one artifact per target. A .dll has its .lib
> import library. A .so may have versioned symlinks. This field could be
> an "artifacts" array or map.
How can I get the directory a library/executable will be put into during the
build?
For libraries the directory should be enough -- that suffices to set up
LD_LIBRARY_PATH or whatever is needed for the system to look up libraries. For
executables (which I need the full path of), the fullName combined with an
artifact directory is probably enough.
I would also like to put the location after "make install", but so far I could
not find how to get that.
> > "linkerLanguage":"C",
> > "name":"cmForm",
> > # "sysroot": "/some/path", if set...
> > "sourceGroups": # Just groups files with similar settings
> > # together to save space
>
> The name "source groups" already has a meaning in CMake. If the goal is
> just to combine sources with the same settings, please use a different name.
>
> > [
> > {
> > "compileFlags":" -std=gnu11",
>
> The format could use the same breakdown that CMake does internally to separate
> target-wide flags from per-source flags. That would also save space, and it
> will be easy for clients to combine the flags.
That would force clients to figure out how to combine the two sets of flags.
Let's keep this knowledge inside cmake, please.
Per-file overrides are probably not as widely used that it makes sense to
optimize for that. At least the difference in output size was not remarkable
with any of the projects I experimented with.
> > "defines":
> > [
> > "CURL_STATICLIB",
> > # <snip>
> > "LIBARCHIVE_STATIC"
> > ],
>
> While not shown in this example, in general the defines can have "=value".
Yes, that is correct and that works:-)
> > "includePath":
> > [
> > "/tmp/cmake-build-test/Utilities",
> > # <snip>
> > "/home/code/src/cmake/Source/CursesDialog/form"
> > ],
>
> Do we need some indication of whether each path is a "system" include dir?
Having that information would not hurt, but is not really critical IMHO.
> > "lanugage":"C",
> > "sources":
> > [
> > "fld_arg.c",
> > # <snip>
> > "fty_regex.c"
> > ]
>
> If we split target flags as mentioned above then we may need an object (map)
> for each source so that it can have fields for per-source flags, defines, etc.
I do not want to do that, see above.
> > "currentBuildDirectory":"/tmp/cmake-build-
> > test/Source/CursesDialog/form",
> > "currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/for
> > m",
>
> As Milian asked in a sibling response, why "current"?
I'll remove the "current" prefix.
Thanks for the feedback!
> Thanks,
> -Brad
>
--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
--
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
