Hi Eric, Thanks for all those details. I wasn't aware that CMake drew a distinction between macros and functions. I'll try to have a look at the ML archives.
- Christian > -----Original Message----- > From: Eric Noulard [mailto:eric.noul...@gmail.com] > Sent: Sunday, June 27, 2010 16:42 > To: Convey, Christian J CIV NUWC NWPT > Cc: alokgo...@hotmail.com; cmake@cmake.org > Subject: Re: [CMake] An observation about CTest > > 2010/6/27 Convey, Christian J CIV NUWC NWPT > <christian.con...@navy.mil>: > > I don't expect a lot of support for what I'm about to say, > but I think it's perhaps worth saying anyway... > > > > It seems like CMake's and CTest's have outgrown their > scripting languages. > > > > As far as I can tell, all CMake/CTest variables are either macro > > formal parameters, or variables in a single global > namespace. I think > > one consequence of this is that macro invocations make their > > contributions primarily by modifying variables in the global > > namespace. As people discovered in the 1970's and 1980's, the > > confusion caused by this approach (global variables) can be > so extensive that it's worthwhile to change coding pracices > (structured programming, etc.), and possibly to improve the > base language as well. > > I think you should dive into the Mailing List archive because > there have been several valuable discussion about CMake > evolution including the "replacement/extension" > of CMake scripting > language with "full language" like Lua or Python. > > > But even better would be enhancing the CMake scripting language to > > support local variables in macros, and possible package-scoped > > variables as well. This clarifies the intended interface > that certain > > macro packages are intended to provide, because variables > intended as implementation details would be in a namespace > inaccessible to the script that invokes those macros. > > CMake is offering scope from a parent/child point of view > including setting variable for your parent with set(xxxx > PARENT_SCOPE) this was indeed provided after lengthly ML discussion. > > Concerning "local variables" you should have a look at the > difference between a "MACRO" and a "FUNCTION" this may > already gives you part of what you want. > > Then as far as I can tell CMake scripting is no-where near a > "must not evolve" language many improvement has been put in > since I began to use CMake 2.2.x (can't remember X) even the > introduction of "POLICY" which each backward compatibility. > > So I think you may not hope to have ALL what you require in > CMake after a message on this ML be you will certainly have > feedback and may be new feature if there is a consensus and > some proof of concept patch provided. > > -- > Erk > Membre de l'April - « promouvoir et défendre le logiciel > libre » - http://www.april.org >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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