Hi Stephen, On Sat, Mar 21, 2015 at 10:56 AM, Stephen Kelly <steve...@gmail.com> wrote: > So, the design question I have is: > > * Is lots of repetition ok in the metadata file?
If it can not be avoided, then so be it. > The answer will be re-used in many other places. For example, if I have a > CMakeLists like > > add_executable(main > file1.cpp > ... > fileM.cpp > ) > target_include_directories(main ...) > target_compile_definitions(main ...) > > then we could either write the definitions and includes once (associated > with the target), or we could repeat them all M times (once for each file). > That could be lots and lots of repetition, repeated N times, once for each > configuration. ... or define a group of files, put all the files into that group and add the other relevant flags. If there is a file that needs something different, then just add that as a separate group. In the normal case where all files have the same flags applied the overhead should be close to the minimum. And it still allows for having different settings for different groups of files without the IDE needing to combine settings. E.g. if main.cpp defined "TEST=1", while the main-target defined "TEST=2", which one will win? Please do not require all IDEs to implement logic found in cmake. There will always be corner cases where this will fail, leading to a broken code model in the IDE. > I personally prefer minimising the repetition, as I did in the unit test I > pushed to my clone. I have the feeling you guys have not looked at the unit > test I pushed to my clone. Please go ahead and do that if not. Also, when > proposing json formats, please imagine how your proposal would represent the > data in Tests/Metadata/CMakeLists.txt. I am not sure I understand cmake well enough to do that correctly:-/ But I'll give it a try. >> I'd actually prefer having a "configurations" key with the list of the >> configurations an object applies to. >> >> That can be optional if the object is relevant to all configurations >> (default in single-configuration generators;-). >> >> This key would then need to be applicable to targets as well as the >> group of source files. >> >> So that would be something like this: > > Could you post what would be generated by your proposed structure for the > unit test file in my branch? > >> That would most likely avoid quite a bit of duplication in the file(s). > > How does the design goal of 'avoid duplication' weigh against the design > goal of 'don't make me combine multiple properties together to get relevant > information (eg target defines and additional source defines)', in general? > > We can either go for one extreme or the other, but I don't think it makes > sense to go for something in between. That would be the worst of both > worlds. > > So, for the proposals which are on the table, please either use the > Metadata/CMakeLists.txt file in my clone, or post an alternative together > with the json which you propose we should generate for it, and a prototype > or pseudo-implementation of a parser for that json. Attached you find something that is close to what I want. I moved the sections in your version of that file around a bit in a text editor, so this might not be valid json:-) This does not really cover the conditions though, as those were not in your file either. Note how the main.cpp is handled differently from your proposal. i do not see configurations as much of a problem in such a setup: Just add them as tags to each group of files (and each target). That way the configurations can be handled just as the other differentiators (language, type) in the file groups/targets. That should reduce the duplication, still be pretty readable and should be reasonably simple to parse. Best Regards, Tobias
cmake-metadata-Linux-GNU-4.9.json
Description: application/json
-- 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
