[CMake] Target property LOCATION doesn't handle DEBUG_POSTFIX

2009-04-30 Thread Stephan Diederich
Hi,

subject says all, here's the CMakeLists.txt:
--
cmake_minimum_required(VERSION 2.6)
project(locate_test)

add_executable(location_test main.cpp)
set_target_properties(location_test PROPERTIES DEBUG_POSTFIX "d")

get_target_property(output location_test LOCATION)
message(${output})
--
running cmake with "cmake ../ -DCMAKE_BUILD_TYPE=Debug" gives:
[...]
-- Detecting CXX compiler ABI info - done
/home/diederich/projects/tests/cmake/build/location_test
-- Configuring done
-- Generating done
-- Build files have been written to: /home/diederich/projects/tests/cmake/build

Is this the expected behaviour?

After digging through Mantis I've found this (somehow) related bug-report:
http://public.kitware.com/Bug/view.php?id=7868
and if I get it right, it states LOCATION can't be used for that.

Problem is, I want to pass a plugin I generate to an executable in
ADD_TEST like this:
ADD_TEST(check_LIBA_for_unresolved_symbols myBinary ${BUILT_PLUGIN}

Any hints how to do this?

Thanks in advance,
Stephan
___
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


Re: [CMake] copy targets into bundles

2008-11-22 Thread Stephan Diederich
On Sat, Nov 22, 2008 at 7:00 PM, Stephan Diederich
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've a CMakeLists.txt which creates two executable tagets. One of them
> is a bundle, the other a command-line utility. Now I want to have (at
> best during build) the helper utility copied into the Resources folder
> of the bundle. I could not find a straightforward way of doing this.
>
> With source files this works out of the box:
> add_executable(MyBundle MACOSX_BUNDLE main.mm test.xml)
> set_source_files_properties(test.xml PROPERTIES MACOSX_PACKAGE_LOCATION
>  Resources)
>
> But how to do it with cmake targets?
>
> The pretty much stripped down version of my CMakeLists.txt:
> add_executable(helperapp main.cpp)
> add_executable(MyBundle MACOSX_BUNDLE main.mm)
> #do something to copy helperapp to MyBundle.app/Contents/Resources


I made some progress and this seems to work:

add_executable(helperapp  main.cpp)
add_executable(MyBundle MACOSX_BUNDLE main.mm )

#and copy helper into it. For now by hand.
#LOCATION seems to miss the .app fix that later..
get_target_property(MF_LOCATION MyBundle LOCATION)
get_target_property(HELPER_LOCATION helperapp LOCATION)
ADD_DEPENDENCIES(MyBundle helperapp)
add_custom_command(TARGET MyBundle
 POST_BUILD
 COMMAND mkdir -p ${MF_LOCATION}.app/Contents/Resources/
 COMMAND cp ${HELPER_LOCATION}
${MF_LOCATION}.app/Contents/Resources/
 COMMENT "add helper" VERBATIM)

still curious if this can be done better...

cheers,
stephan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] copy targets into bundles

2008-11-22 Thread Stephan Diederich
Hi,

I've a CMakeLists.txt which creates two executable tagets. One of them
is a bundle, the other a command-line utility. Now I want to have (at
best during build) the helper utility copied into the Resources folder
of the bundle. I could not find a straightforward way of doing this.

With source files this works out of the box:
add_executable(MyBundle MACOSX_BUNDLE main.mm test.xml)
set_source_files_properties(test.xml PROPERTIES MACOSX_PACKAGE_LOCATION
  Resources)

But how to do it with cmake targets?

The pretty much stripped down version of my CMakeLists.txt:
add_executable(helperapp main.cpp)
add_executable(MyBundle MACOSX_BUNDLE main.mm)
#do something to copy helperapp to MyBundle.app/Contents/Resources

Thanks for any pointers,
Stephan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


Re: [CMake] qmake / cmake moc options consistency

2008-08-07 Thread Stephan Diederich
On Thu, Aug 7, 2008 at 2:39 AM, Clinton Stimpson <[EMAIL PROTECTED]> wrote:
> On Jul 31, 2008, at 8:12 AM, Stephan Diederich wrote:
>> Hi,
>>
>> I just found an issue while moc'ing one of our headers.
>> We have some #ifndeffed slots in that header which depend on -DWIN32.
>> A default qmake ".pro" project adds
>> -D_MSC_VER=1400 -DWIN32
>> on windows, MSVC8. The  QT4_WRAP_CPP does not define WIN32.
>> (_WIN32 seems to be defined by, but I've no idea where it comes from)
>>
>> I could work around the problem by using the options from QT4_WRAP_CPP
>> like this:
>> QT4_WRAP_CPP(projects_MOC_SRCS ${projects_MOC_HDRS} OPTIONS "-DWIN32").
>>
>> Is this just an oversight?
>>
>>
>
> Yes, it is an oversight.  Could you make a bug report for this, so it
> doesn't get lost?

sure: http://public.kitware.com/Bug/view.php?id=7465

cheers,
stephan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] qmake / cmake moc options consistency

2008-07-31 Thread Stephan Diederich
Hi,

I just found an issue while moc'ing one of our headers.
We have some #ifndeffed slots in that header which depend on -DWIN32.
A default qmake ".pro" project adds
-D_MSC_VER=1400 -DWIN32
on windows, MSVC8. The  QT4_WRAP_CPP does not define WIN32.
(_WIN32 seems to be defined by, but I've no idea where it comes from)

I could work around the problem by using the options from QT4_WRAP_CPP
like this:
QT4_WRAP_CPP(projects_MOC_SRCS ${projects_MOC_HDRS} OPTIONS "-DWIN32").

Is this just an oversight?

cheers,
Stephan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake


[CMake] Visual Studio, Solutions and dependant projects

2007-09-17 Thread Stephan Diederich
Hi,

I want to reanimate discussions about (Visual Studio) support for the
following sourcecode layout:

Toplevel
|
-CMakeLists.txt (sets all common stuff)
-apps
   -CMakeLists.txt (adds only the different apps with add_subdirectory(...))
   |
   - App1
  - CMakeLists.txt (project(app1), add_executable(app1 ...),
target_link_libraries(app1lib1)
   |
   - App2
  - CMakeLists.txt (project(app2), add_executable(app2 ...),
target_link_libraries(app1lib1 lib2)
|
-libs
   -CMakeLists.txt (adds only the different libs with add_subdirectory(...))
   |
   - lib1
  - CMakeLists.txt (project(lib1), ...)
   |
   - lib2
  - CMakeLists.txt


I think the behaviour with Visual-Studio and Makefiles differs for
those projects. If I cd into $(BUILDDIR)/apps/app1, and do make, the
libraries (lib1 in this case) is build before the app. In Visual
Studio, that lib isn't build, and its .vcproj file isn't included in
the solution for app1.

I know it is possible to open the toplevel solution and then
everything is build fine, but for a project tree where there are many
targets the toplevel solution becomes easily cluttered and it would be
nicer to directly use the solution from the target one wants to build
(e.g. app1).

There were already several discussions about this topic on this list
(http://tinyurl.com/2s3e69 , http://tinyurl.com/3c29em) and there is a
bugreport with an attached patch from Manuel Klimek
(http://preview.tinyurl.com/3bg4za).
But actually I could not read the opinion from CMake-developers about
this issue. Will the patch be included? Are there problems one should
now?

Thanks in advance,
Stephan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake