On 2008-05-07 15:18-0700 Alan W. Irwin wrote:
I used your FOREACH example in my post, but it is really this expansion inconsistency in all contexts which bothers me. Your answer so far is essentially "we have always done it that way". Perhaps there are excellent practical reasons for that language quirk that are obvious to you, but I cannot think of what those might be at the moment so I would appreciate your help in identifying those practical reasons.
Never mind, I have thought of them now. I thought the POLICY mechanism would be enough to keep backwards compatibility for existing build systems, and therefore it would be straightforward to change the language to improve its consistency for build systems implemented in the future. However, that is an overly simplistic view. In my zeal to have more consistency in the language, I forgot about the existing body of macros that come with CMake. If this language quirk is fixed there is bound to be some LIST variable expansion in those macors that will screw up in obscure ways that will depend on whether platform- and user-dependent LIST variables have empty values or not. So unfortunately I think we are stuck with this particular language inconsistency. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake