Hi Bill, Wouldn't it be better if CMake kept track of these variables internally. I mean, usually the HAS_X variables are the result of calls to check_include_file() and check_function_exists(). The Autotools handle this under the hood. CMake might keep a list of these variables, possibly one per check_*() function. Or is there a reason to let the user handle this explicitly by specifying the list of HAS_X variables in the call to cmake_autoheader()?
Best regards, Marcel Loose. On Mon, 2009-03-30 at 11:58 -0400, Bill Hoffman wrote: > Hendrik Sattler wrote: > > Zitat von Bill Hoffman <bill.hoff...@kitware.com>: > > > >> I have seen several requests for an autoheader type function to be > >> added to CMake. I have never used autoheader, but I gather it takes a > >> list of variables and generates a config.h.in file automatically. Does > >> anyone on the list have experience with autoheader? If so, what would > >> a nice CMake api for something like this look like? > > > > Well, autoheader just takes the result of certain tests and prepares a > > file that is usable e.g. with configure_file( .... @ONLY ). Usually, > > that contains much more than anyone needs or wants. > > It addresses the problem of not having to keep to distinct lists of > > variables to replace (avoiding typos) but limits itself to a strict format. > > > > A cmake-equalvalent could be a configure_file()-like function that takes > > a list of variables or mark variables and use all of them. There is no > > point in emulating the actual autoheader behaviour as that has the same > > problem as the configure script itself: an automatically created (and > > thus non-source) file in the source tree. > > You can even make it better than autoheader and emit a file with > > #define/#undef for C and something with const variables for C++ (type > > safety) and something else for other supported languages. That would > > make it more complex but definitely better. > > > > So, what would the API be? I am thinking something that you just give a > list of variables and a file name. > > set(VARS HAS_A HAS_B HAS_C) > set(STRING_VARS STRING_A STRING_B) > cmake_autoheader(CMAKEDEFINE_VARS ${VARS} > STRING_VARS ${STRING_VARS} > HEADER config.h.in) > > > This would create: > config.h.in > #cmakedefine HAS_A > #cmakedefine HAS_B > #cmakedefine HAS_C > #define STRING_A "@STRING_A@" > #define STRING_B "@STRING_B@" > > > I think you could do this pretty easily in a function, and a command > would not be needed. Anyway, does the API look good? > > -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 _______________________________________________ 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