Re: [CMake] Visualizing all build-system options
On 9/24/2011 1:08 PM, Brian Davis wrote: > I guess at the end of the day what you are talking about is a static code analysis tool for the CMake language. Those tools look at all possible branches of code and try to detect errors. What I would like to see at a minimum is a CMake Debugger showing a window with the list of variables, not just the ones in the name/values dialog in the GUI, that an be searched when say CMake Errors out and dumps an error to the output text field in the GUI. This way I could see what all the variables are in the active cmake file being parsed without having to message them to the screen. just going though the messages and found this recently. cmake --trace might be helpful to you. I have been thinking it might be cool to also show the value of any variable referenced on a line during the trace. --trace-show-vars or something like that. I don't have time to work on it, but it should be pretty easy to do if someone wanted to create a patch. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visualizing all build-system options
> I guess at the end of the day what you are talking about is a static code analysis tool for the CMake language. Those tools look at all possible branches of code and try to detect errors. What I would like to see at a minimum is a CMake Debugger showing a window with the list of variables, not just the ones in the name/values dialog in the GUI, that an be searched when say CMake Errors out and dumps an error to the output text field in the GUI. This way I could see what all the variables are in the active cmake file being parsed without having to message them to the screen. just going though the messages and found this recently. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visualizing all build-system options
On 9/1/2011 8:48 PM, Alan W. Irwin wrote: Yeah, it is fun to speculate about something new like this that would be of considerable benefit to help a project's developers and users visualize the complete set of options and their dependencies for their project's build system. Unfortunately I don't have sufficient knowledge of the CMake code base (or C++ for that matter) to do this myself, and I assume nobody at Kitware has spare time to do such an implementation. However, maybe someone else here or perhaps a GSOC student next year might be interested in fleshing this idea out into something useful. I guess at the end of the day what you are talking about is a static code analysis tool for the CMake language. Those tools look at all possible branches of code and try to detect errors. Although not impossible, this would not be something that could be hacked out quickly. As a rough order, I would put this at several man months of effort. Maybe a GSOC... -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visualizing all build-system options
On 2011-09-01 18:00-0400 David Cole wrote: Sounds like a great research project for somebody. Would be cool to see CMake options visualized for some larger projects... Not sure of its feasibility in terms of completeness, however. I'm sure you could come up with something rudimentary that seems to work for some cases. There are some cases that you will simply never reach, even though the code is in there. For example, consider what happens when you have this code: if(WIN32) option(SOME_WIN32_SPECIFIC_OPTION ...) endif() And then you run your tool on your Linux box. I don't care how many iterations you do, you're simply never going to see the platform specific option. Also, in order to aim for completeness, you'd need to deal with potential code like this: if(optA AND optB AND optC AND optD OR NOT (optE AND optF)) option(REALLY_WELL_HIDDEN_OPTION ...) endif() Basically, the "inner" option will only be triggered in a very specific set of true-false values of all the "outer" options... The combinatorial nature of the arbitrary logic enabled by the IF command makes it very difficult for an analysis tool like this to achieve "guaranteed completeness." However, even without completeness, it would still be a neat tool, and I'd love to see what sorts of graphs are out there in the wild. Hi Dave: Interesting examples. I suspect that graphviz can handle all sorts of different types of relationships, but if you just focus on dependencies alone (and not what those dependencies are), then I believe that all graphviz would need to know is that SOME_WIN32_SPECIFIC_OPTION depended on the WIN32 variable and REALLY_WELL_HIDDEN_OPTION depended on the optA, optB, etc., option variables. The cmake parser presumably skips everything inside the if(WIN32) block on a Linux system so I guess you would have to go to an external tool (or a special CMake parsing mode) to parse every CMake logic branch to discover all dependencies. But that could obviously be done to collect information on all option dependencies. I think you will agree with me that the the interesting visualization results would be for option dependencies since those dependencies are the ones that complicate the art of CMake configuration. However, from your first example the intrusion of non-option variables in the dependency visualization system would obviously be a necessary extension of my original idea. So you would have to include non-option variables in the dependency tree for options as well, but to simplify the final graph concerning option dependencies it would probably be a good idea to drop all variables from the results which were not depended upon by option variables. - 2 cents worth... :-) Yeah, it is fun to speculate about something new like this that would be of considerable benefit to help a project's developers and users visualize the complete set of options and their dependencies for their project's build system. Unfortunately I don't have sufficient knowledge of the CMake code base (or C++ for that matter) to do this myself, and I assume nobody at Kitware has spare time to do such an implementation. However, maybe someone else here or perhaps a GSOC student next year might be interested in fleshing this idea out into something useful. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visualizing all build-system options
Sounds like a great research project for somebody. Would be cool to see CMake options visualized for some larger projects... Not sure of its feasibility in terms of completeness, however. I'm sure you could come up with something rudimentary that seems to work for some cases. There are some cases that you will simply never reach, even though the code is in there. For example, consider what happens when you have this code: if(WIN32) option(SOME_WIN32_SPECIFIC_OPTION ...) endif() And then you run your tool on your Linux box. I don't care how many iterations you do, you're simply never going to see the platform specific option. Also, in order to aim for completeness, you'd need to deal with potential code like this: if(optA AND optB AND optC AND optD OR NOT (optE AND optF)) option(REALLY_WELL_HIDDEN_OPTION ...) endif() Basically, the "inner" option will only be triggered in a very specific set of true-false values of all the "outer" options... The combinatorial nature of the arbitrary logic enabled by the IF command makes it very difficult for an analysis tool like this to achieve "guaranteed completeness." However, even without completeness, it would still be a neat tool, and I'd love to see what sorts of graphs are out there in the wild. - 2 cents worth... :-) David C. On Thu, Sep 1, 2011 at 5:38 AM, Alan W. Irwin wrote: > I was just replying to an acquaintance who was e-mailing me about CMake > configuration when I realized that CMake configuration options > which are only available depending on how other configuration > options are set could be analyzed/displayed using graph theory > (from a 5-minute study of graph theory from reading the first > paragraph of the Wikipedia article on that :-) ). > > I looked for a graphviz output file option for this in the cmake > documentation and only found the --graphviz option which will > "Generate a graphviz input file that will contain all the library and > executable dependencies in the project." I used that for PLplot once. > It worked and gave a pretty impressive visual demonstration of all the > complicated and numerous PLplot dependencies. I wasn't surprised by > any of those detailed relationships because I have them pretty much > memorized, but such information would be a definite help to someone > just getting up to speed with the PLplot build system (or any > CMake-based build system) > > Could something similar be done for the dependencies between CMake > options? I think that would be quite useful (especially if it > included the documentation of the options) for further graphviz > analysis and display of the > relationships between the totality of all the CMake options for a > given build system. The problem with using cmake-gui for this task > (or the equivalent cmake + looking at the resulting CMakeCache.txt > file) is you only see the first layer of possible configurations as > opposed to the totality of options you could visualize with a graphviz > file. > > Moving to a related topic, if you run cmake with no -D options in an > empty build tree, you get the first layer of options available to you > for a particular build system in nicely documented form in > CMakeCache.txt. Once you set some of those as cmake -D options > (always run within an empty build tree), then you get the next layer > of options available to you, and so on, with each iteration > accumulating the command-line -D options you need from the combination > of previous sets of options and the new ones. > > I am not familiar with the CMake GUI's, cmake-gui and ccmake, but I > assume they do exactly this same task of displaying the documented > currently available options that can be set depending on the previous > "layer" of set options. But do any of these GUI's have an undo button > (and redo button to undo the undo) so you can easily and consistently > navigate to any previous layer of options that you have effectively > tried before for an empty build tree like you can so easily do (simply > using up arrow or down arrow to remove the build tree and navigate to > some other previously tried set of -D options) with the command-line > approach? It appears from discussions with my GUI-oriented > acquaintance, undo and redo buttons would be worthwhile now if those > haven't been implemented yet in the CMake GUI's. > > I hope in this post I have given this audience some useful food for > thought about potential improvements to CMake concerning (1) a > graphviz output file of all options including their documentation to > help display an overview of all options and their logical > relationships and (2) possibly additional ease of use for CMake GUI's > with undo and redo (if those haven't been implemented yet) in setting > various layers of those options that become available depending on > other options set in previous layers. I admit to being unfamiliar with > the CMake GUI's (because I was not impressed with them years ago), but > if they already have undo a
[CMake] Visualizing all build-system options
I was just replying to an acquaintance who was e-mailing me about CMake configuration when I realized that CMake configuration options which are only available depending on how other configuration options are set could be analyzed/displayed using graph theory (from a 5-minute study of graph theory from reading the first paragraph of the Wikipedia article on that :-) ). I looked for a graphviz output file option for this in the cmake documentation and only found the --graphviz option which will "Generate a graphviz input file that will contain all the library and executable dependencies in the project." I used that for PLplot once. It worked and gave a pretty impressive visual demonstration of all the complicated and numerous PLplot dependencies. I wasn't surprised by any of those detailed relationships because I have them pretty much memorized, but such information would be a definite help to someone just getting up to speed with the PLplot build system (or any CMake-based build system) Could something similar be done for the dependencies between CMake options? I think that would be quite useful (especially if it included the documentation of the options) for further graphviz analysis and display of the relationships between the totality of all the CMake options for a given build system. The problem with using cmake-gui for this task (or the equivalent cmake + looking at the resulting CMakeCache.txt file) is you only see the first layer of possible configurations as opposed to the totality of options you could visualize with a graphviz file. Moving to a related topic, if you run cmake with no -D options in an empty build tree, you get the first layer of options available to you for a particular build system in nicely documented form in CMakeCache.txt. Once you set some of those as cmake -D options (always run within an empty build tree), then you get the next layer of options available to you, and so on, with each iteration accumulating the command-line -D options you need from the combination of previous sets of options and the new ones. I am not familiar with the CMake GUI's, cmake-gui and ccmake, but I assume they do exactly this same task of displaying the documented currently available options that can be set depending on the previous "layer" of set options. But do any of these GUI's have an undo button (and redo button to undo the undo) so you can easily and consistently navigate to any previous layer of options that you have effectively tried before for an empty build tree like you can so easily do (simply using up arrow or down arrow to remove the build tree and navigate to some other previously tried set of -D options) with the command-line approach? It appears from discussions with my GUI-oriented acquaintance, undo and redo buttons would be worthwhile now if those haven't been implemented yet in the CMake GUI's. I hope in this post I have given this audience some useful food for thought about potential improvements to CMake concerning (1) a graphviz output file of all options including their documentation to help display an overview of all options and their logical relationships and (2) possibly additional ease of use for CMake GUI's with undo and redo (if those haven't been implemented yet) in setting various layers of those options that become available depending on other options set in previous layers. I admit to being unfamiliar with the CMake GUI's (because I was not impressed with them years ago), but if they already have undo and redo implemented perhaps it is time to learn about them (and especially if they are exactly equivalent to the situation I understand which is running cmake in an empty build tree with various layers of possible -D options set on the cmake command line). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
