[CMake] Quick question about set and substitutions

Fri Sep 17 03:42:31 EDT 2010

So, you want to embed the "basename" of the output file in the target, right? In that case you should be aware of the fact that variables/properties like CMAKE_<config>_POSTFIX can change your name and with mult-config generators you don't know what <config> is at configure-time. AFAIK there is currently no reliable way of obtaining the exact output name of a target for mult-config generators.

I think it would be much safer to use something like this:

config.h
--------
#pragma once
#ifndef CONFIG_H
#define CONFIG_H
#ifdef __cplusplus
extern "C" {
#endif

extern const char* FILE_NAME;

#ifdef __cplusplus
}
#endif
#endif
/* EOF */

config.c.in
-----------
#include "config.h"

#ifndef CONFIG_SUFFIX
#define CONFIG_SUFFIX ""
#endif

const char* FILE_NAME = "@CMAKE_SHARED_LIBRARY_PREFIX@@PROJECT_NAME@" CONFIG_SUFFIX "@CMAKE_SHARED_LIBRARY_SUFFIX@";

/* EOF */

CMakeLists.txt
--------------
cmake_minimum_required(VERSION 2.6 FATAL_ERROR)
project(super)

# set config-dependent name suffixes
set(CMAKE_DEBUG_POSTFIX _debug)
set(CMAKE_RELEASE_POSTFIX _release)
set(CMAKE_RELWITHDEBINFO_POSTFIX _reldeb)
set(CMAKE_MINSIZEREL_POSTFIX _minrel)

include_directories(${CMAKE_SOURCE_DIR})

configure_file(config.c.in ${CMAKE_BINARY_DIR}/config.c)

add_library(${PROJECT_NAME} SHARED ${CMAKE_BINARY_DIR}/config.c super.cpp)

# this is the crucial part where we set CONFIG_SUFFIX on the compile-line of config.c
# depending on the configuration. for non-IDE generators CMAKE_BUILD_TYPE may also be empty,
# which we catch in config.c.
set_source_files_properties(${CMAKE_BINARY_DIR}/config.c PROPERTIES
  COMPILE_DEFINITIONS_DEBUG CONFIG_SUFFIX="${CMAKE_DEBUG_POSTFIX}"
  COMPILE_DEFINITIONS_RELEASE CONFIG_SUFFIX="${CMAKE_RELEASE_POSTFIX}"
  COMPILE_DEFINITIONS_RELWITDEBINFO CONFIG_SUFFIX="${CMAKE_RELWITHDEBINFO_POSTFIX}"
  COMPILE_DEFINITIONS_MINSIZEREL CONFIG_SUFFIX="${CMAKE_MINSIZEREL_POSTFIX}")

# EOF

HTH

Michael

On 17. Sep, 2010, at 6:43 , J Decker wrote:

> On Thu, Sep 16, 2010 at 7:40 PM, Ryan Pavlik <rpavlik at iastate.edu> wrote:
>> Your "project" command should always be the first or second (after
>> cmake_minimum_required) command in your root CMakeLists.txt file, unless you
>> have a very good reason.
>> 
>> Then, on the topic of definitions, this is all you need:
>> add_definitions("-DLIBRARY_NAME=\"${YOUR_CMAKE_VAR_WITH_LIB_NAME}\"")
>> before you add your target (add_library, etc) - CMake will automatically
>> pull the var=value part out, and do quoting appropriate for your compiler.
>> see
>> also: http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:COMPILE_DEFINITIONS  (for
>> details and/or another way to achieve the same result, but in a more
> 
> okay that's wonderful thanks; AND doesn't require -D like add_definitions...
> 
>> fine-grained, per-target way that probably is appealing given your goal)
>> I was hoping that there was an easy solution - hope this helps!
>> Ryan
>> On Thu, Sep 16, 2010 at 8:42 PM, J Decker <d3ck0r at gmail.com> wrote:
>>> 
>>> On Thu, Sep 16, 2010 at 6:30 PM, Ryan Pavlik <rpavlik at iastate.edu> wrote:
>>>> Why are you trying to do this before the project command?
>>> 
>>> 
>>> To result in a shorthand that I don't HAVE to copy and paste; because
>>> definition of compiler requirements for passing definitions that are
>>> string literals is lacking?
>>> 
>>> 
>>> You can set the
>>>> target name to be something different from the project name, and you can
>>>> even set the output name of the executable/library to be different than
>>>> what
>>>> would be automatically set by default from the target name.
>>> 
>>> 
>>> Sure... but I don't; so it would be a reasonable shorthand within this
>>> source domain.
>>> 
>>> 
>>> (I've done
>>>> this, to embed the platform into the code and/or output name)
>>>> My guess: you've done a lot of work with makefiles and the C
>>>> preprocessor.
>>>> It looks like you're overthinking it - CMake is a reasonably high-level
>>>> scripting language, not a macro language or preprocessor.
>>> 
>>> 
>>> Maybe :) That's really the question though - how is this not what I want?
>>> 
>>> 
>>>> Could you share a high-level intended behavior with the list so we might
>>>> be
>>>> able to give you a more satisfying answer?
>>> 
>>> 
>>> In the end, during compilation I want to define a 'variable' that IS
>>> the name of the library itself.  That name is usually only passed to
>>> the linker.  different compilers have different syntax for defining
>>> string literals like
>>> 
>>> #define TARGET_NAME "MyLibrary.Dll"
>>> 
>>> I don't want to define the name in two places, I want it to be
>>> definitively the project name, because why would it be any other name
>>> in a new development?
>>> 
>>> gcc[ld] -DTARGET_NAME="\"libsack.so\"" -o libsack.so <sources>
>>> 
>>> wcc[wlink] -DTARGET_NAME="libsack.so" -o sack.dll <sources>
>>> 
>>> /* I'm not sure about this one... it might be like gcc, but it may be
>>> version dependant also */
>>> mc[link] -DTARGET_NAME="libsack.so" -o sack.dll <sources>
>>> 
>>> Since there is no definition in CMAKE for the quote to use to define a
>>> string literal to a definition...
>>> 
>>> I think is the syntax to define a macro on the command line that has
>>> spaces, not strings... really probably openwatcom is broken.
>>> 
>>> "-DOtherMacro 1+2=3"
>>> _______________________________________________
>>> 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
>> 
>> 
>> 
>> --
>> Ryan Pavlik
>> HCI Graduate Student
>> Virtual Reality Applications Center
>> Iowa State University
>> 
>> rpavlik at iastate.edu
>> http://academic.cleardefinition.com
>> Internal VRAC/HCI Site: http://tinyurl.com/rpavlik
>> 
> _______________________________________________
> 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

--
There is always a well-known solution to every human problem -- neat, plausible, and wrong.
H. L. Mencken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100917/d058ac4a/attachment-0001.pgp>