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 <rpav...@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 <d3c...@gmail.com> wrote:
>>>
>>> On Thu, Sep 16, 2010 at 6:30 PM, Ryan Pavlik <rpav...@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
>>
>> rpav...@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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ 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
