Am Montag 30 März 2009 17:58:47 schrieb Bill Hoffman:
> 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?
Why do you want to create a config.h.in like that? autoheader is a two-step
thing and both steps can be done during _one_ cmake run. There is no sense in
creating config.h.in just to use configure_file() on it the next moment.
create_configuration_header (config.h
LANGUAGE C
TYPE INTEGER ${INTEGER_VARIABLE_NAME_LIST}
TYPE BOOLEAN ${BOOLEAN_VARIABLE_NAME_LIST}
TYPE STRING ${STRING_VARIABLE_NAME_LIST}
}
That should create config.h like for C:
/* add some boolean include stuff here */
#define INTEGER_X 1234L
#define BOOL_B true
#define STRING_S "hello world"
HS
_______________________________________________
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
