2011/2/13 Alexander Neundorf <neund...@kde.org>: > On Monday 07 February 2011, Alexander Neundorf wrote: >> On Sunday 06 February 2011, Eric Noulard wrote: >> > 2011/2/5 Alexander Neundorf <neund...@kde.org>: >> > > Hi, >> > > >> > > in general we keep cmake as backward compatible as possible, so no >> > > builds are broken. >> > > >> > > In a local branch I have a version of cmake with a small improvement to >> > > the graphviz support in cmake. >> > > It turns the variable GRAPHVIZ_IGNORE_TARGETS from a list of strings >> > > into a list of regular expressions. I.e. everything which was before in >> > > GRAPHVIZ_IGNORE_TARGETS and excluded from the dot-files, is now still >> > > excluded, but now there may be more targets excluded (e.g. for "kio" >> > > now not only "kio" is excluded, but also "kio_ftp" etc.) >> > > Also, with this change, the variable GRAPHVIZ_TARGET_IGNORE_REGEX is >> > > not supported anymore, so targets previously excluded from the >> > > dot-files via this (one) regex are now included. >> > > >> > > Both issues can be fixed by, for the first, putting "^...$" around the >> > > string, and for the second by just putting the regex now into >> > > GRAPHVIZ_IGNORE_TARGETS . >> > > >> > > Strictly speaking, this breaks compatibility regarding the graphviz >> > > support. But, do we care about this ? >> > > * it is and was completely undocumented (will write a wiki page soon) >> > > * the changes don't influence the build itself, so no build can be >> > > broken by this change >> > > >> > > What do you think ? >> > >> > I think that, I didn't even know the existence of this, so I wouldn't >> > care about breaking it :-] >> > Moreover I am basically ok that the breakage of an undocumented feature >> > is not a real breakage. >> > >> > Now may be you can: >> > 1) rename GRAPHVIZ_IGNORE_TARGETS to "CMAKE_GRAPHVIZ_IGNORE_TARGETS" >> > which is more consistent with other var names. >> > >> > 2) check GRAPHVIZ_IGNORE_TARGETS and GRAPHVIZ_TARGET_IGNORE_REGEX >> > and issue a WARNING if they are used. >> > >> > 2) may even be unecessary with the new "--warn-unused-vars" option. >> > >> > the baseline is if you break it, then break it ALL there won't be any >> > confusion. >> >> I could also make these variables cache variables. >> That's IMO easier to use and also better discoverable. >> With "GRAPHVIZ_IGNORE_TARGETS" they would be all in the "GRAPHVIZ" subtree, >> with "CMAKE_GRAPHVIZ_IGNORE_TARGETS" they would be all together with the >> other cmake variables in the "CMAKE" subtree. >> >> Being in a "GRAPHVIZ" subtree would make them easier to spot, so maybe I'd >> prefer this. But I don't have a strong opinion. >> >> Other comments ? > > I guess this means that backward compatibility is no issue here. > > Eric, what do you think about the naming and whether make them cache variables > or not ?
Naming scheme with GRAPHVIZ prefix is good you are right for the subtree thing. Caching looks ok too, I don't think such var needs to be seen at first sight. My opinion may not be that valuable in this area because I'm not using the feature :-] Now the argument of the subtree is a good one even if we can think that sub-subtree (more than one level tree) may be implemented in cmake-gui too. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
