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
