[CMake] Make project name a target

2009-09-11 Thread Marcel Loose
Hi all,

I was wondering whether it's a good idea to make the project name (i.e.
the argument to the 'project' command) a target. 

Rationale: I have a project that consists of numerous sub-projects and I
would like to be able to build some of these separately. Wrapping the
'project' command in a macro is not a solution, because AFAIK CMake
*must* see a 'project' command in the top-level CMakeLists.txt file; a
'myproject' macro, wrapping the 'project' command, will not do.

Any comments?

Best regards,
Marcel Loose.


___
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] Make project name a target

2009-09-11 Thread David Cole
When you say make the project name a target what do you mean by that?
(1) internally create a CMake target with the given name?
(2) create a makefile target with that name that builds all the cmake
targets in that cmake project?
(3) something else?

(1) is probably not feasible for most folks -- because many people use the
same name for their PROJECT statement and the main library or executable for
that project which is already a cmake target (and a makefile target)
with that name.


On Fri, Sep 11, 2009 at 3:51 AM, Marcel Loose lo...@astron.nl wrote:

 Hi all,

 I was wondering whether it's a good idea to make the project name (i.e.
 the argument to the 'project' command) a target.

 Rationale: I have a project that consists of numerous sub-projects and I
 would like to be able to build some of these separately. Wrapping the
 'project' command in a macro is not a solution, because AFAIK CMake
 *must* see a 'project' command in the top-level CMakeLists.txt file; a
 'myproject' macro, wrapping the 'project' command, will not do.

 Any comments?

 Best regards,
 Marcel Loose.


 ___
 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

[CMake] add_subdirectory and build directory

2009-09-11 Thread Pierre-Julien Villoud
Hi everyone,

After unsuccessfully looking for an answer on Google, I contact you.
I have a question regarding the use of add_subdirectory. When a project A is 
depending on a project B, I add the following in A's CMakeLists.txt :

Add_subdirectory(B Path/To/B/Build/Directory)

It does build B before A. But when I build B in its build directory and I build 
A after, it builds B again whereas it should not since B is up to date.

Anyone sees what's wrong ?

Thanks in advance

Pierre-Julien VILLOUD
___
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] Make project name a target

2009-09-11 Thread Marcel Loose
Hi David,

I don't see the exact difference between (1) and (2). And yes, I was
thinking of using the project name as a target. You are right, that it
might cause clashes with existing projects, though :-(

We use the convention that project names are always capitalized, so we
usually don't run into problems.

Is there a nifty trick to wrap the 'project' command? I never succeeded
in doing that.

Best regards,
Marcel Loose.


On Fri, 2009-09-11 at 07:09 -0400, David Cole wrote:
 When you say make the project name a target what do you mean by
 that?
 
 
 (1) internally create a CMake target with the given name?
 (2) create a makefile target with that name that builds all the cmake
 targets in that cmake project?
 (3) something else?
 
 
 (1) is probably not feasible for most folks -- because many people use
 the same name for their PROJECT statement and the main library or
 executable for that project which is already a cmake target (and a
 makefile target) with that name.
 
 
 
 On Fri, Sep 11, 2009 at 3:51 AM, Marcel Loose lo...@astron.nl wrote:
 Hi all,
 
 I was wondering whether it's a good idea to make the project
 name (i.e.
 the argument to the 'project' command) a target.
 
 Rationale: I have a project that consists of numerous
 sub-projects and I
 would like to be able to build some of these separately.
 Wrapping the
 'project' command in a macro is not a solution, because AFAIK
 CMake
 *must* see a 'project' command in the top-level CMakeLists.txt
 file; a
 'myproject' macro, wrapping the 'project' command, will not
 do.
 
 Any comments?
 
 Best regards,
 Marcel Loose.
 
 
 ___
 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


Re: [CMake] add_subdirectory and build directory

2009-09-11 Thread Michael Wild


On 11. Sep, 2009, at 15:12, Pierre-Julien Villoud wrote:


Hi everyone,

After unsuccessfully looking for an answer on Google, I contact you.
I have a question regarding the use of add_subdirectory. When a  
project A is depending on a project B, I add the following in A's  
CMakeLists.txt :


Add_subdirectory(B Path/To/B/Build/Directory)

It does build B before A. But when I build B in its build directory  
and I build A after, it builds B again whereas it should not since B  
is up to date.


Anyone sees what's wrong ?

Thanks in advance

Pierre-Julien VILLOUD



That's NOT what add_subdirectory is made for. It is intended for  
adding a sub-directory in the source tree. So, if your directory  
structure looks like this (i.e. B is a sub-project of A)


A/CMakeLists.txt
A/B/CMakeLists.txt

things are simple:

A/CMakeLists.txt:
--8--
# 
add_subdirectory(B)

include_directories(B/include)

add_executable(a)
target_link_libraries(a b)
--8--

However, if the two projects are unrelated (apart from A depending on  
B), you should use the find_package mechanism which is much more  
complex. I.e, in project B you create the files BConfig.cmake (or b- 
config.cmake), BUse.cmake, BBuildSettings.cmake and  
BLibraryDepends.cmake:


B/BConfig.cmake.in:
---8--
# Tell the user project where to find our headers and libraries
set(B_INCLUDE_DIRS @CONFIG_HEADER_PATH@)
set(B_LIBRARY_DIRS @CONFIG_LIBRARY_PATH@)

# Our build settings and library dependencies
set(B_BUILD_SETTINGS_FILE
  @CONFIG_LIBRARY_PATH@/BBuildSettings.cmake
  )
include(@CONFIG_LIBRARY_PATH@/BLibraryDepends.cmake)

# Defines
set( B_DEFINITIONS @CONFIG_DEFINITIONS@ )

# USE file
set(B_USE_FILE @CONFIG_USE_FILE_PATH@/BUse.cmake)
--8--

B/BUse.cmake:
---8--
# import B build settings
include(CMakeImportBuildSettings)
cmake_import_build_settings(${B_BUILD_SETTINGS_FILE})

# set up header search path
include_directories(${B_INCLUDE_DIRS})

# set up library search path
link_directories(${BM_LIBRARY_DIRS})

# defines
add_definitions(${B_DEFINITIONS})
--8--

In the B/CMakeLists.txt file you do the following (just a snippet,  
showing the relevant stuff):


B/CMakeLists.txt:
--8--
# 

# say, you build two libraries, called b1 and b2
# with sources b1src1.c through b1src3.c and
# b2src1.c through b2src3.c, respectively.
add_library(b1 b1src1.c b1src2.c b1src3.c)
set_target_properties(b1 PROPERTIES
  PUBLIC_HEADER b1hdr1.h;b1hdr2.h;b1hdr3.h
  )

add_library(b2 b2src1.c b2src2.c b2src3.c)
set_target_properties(b2 PROPERTIES
  PUBLIC_HEADER b2hdr1.h;b2hdr2.h;b2hdr3.h
  )

# 

# install the two libraries
install(TARGETS b1 b2
  LIBRARY DESTINATION lib COMPONENT shlibs
  RUNTIME DESTINATION bin COMPONENT shlibs
  ARCHIVE DESTINATION lib COMPONENT dev
  PUBLIC_HEADER DESTINATION include COMPONENT dev
  )

# 

# AT THE VERY END OF THE FILE...

# Export library dependencies
#
export( TARGETS b1 b2
  NAMESPACE B_
  FILE ${CMAKE_BINARY_DIR}/BLibraryDepends.cmake
)

# Export the build settings
###
include(CMakeExportBuildSettings)
cmake_export_build_settings(${CMAKE_BINARY_DIR}/BBuildSettings.cmake)

# create BConfig.cmake for the build tree
#
# SET TO THE PREPROCESSOR FLAGS REQUIRED TO USE PROJECT B
set(CONFIG_DEFINITIONS)
# SET TO WHATEVER INCLUDE PATH IS REQUIRED TO USE B'S BINARY TREE
set(CONFIG_HEADER_PATH ${CMAKE_SOURCE_DIR}/include )
# SET TO WHATEVER LIBRARY PATH IS REQUIRED TO USE B'S BINARY TREE
# (ACTUALLY, DUE TO CMAKE-MAGIC THIS CAN BE EMPTY)
set(CONFIG_LIBRARY_PATH)
set(CONFIG_USE_FILE_PATH ${CMAKE_SOURCE_DIR})
configure_file(
  ${CMAKE_SOURCE_DIR}/BConfig.cmake.in
  ${CMAKE_BINARY_DIR}/BConfig.cmake
  @ONLY
  )

# create BConfig.cmake for the install tree
###
set(CONFIG_HEADER_PATH ${CMAKE_INSTALL_PREFIX}/include)
set(CONFIG_LIBRARY_PATH ${CMAKE_INSTALL_PREFIX}/lib)
set(CONFIG_USE_FILE_PATH ${CMAKE_INSTALL_PREFIX}/share/cmake/B )
configure_file(
  ${CMAKE_SOURCE_DIR}/BConfig.cmake.in
  ${CMAKE_BINARY_DIR}/InstallFiles/BConfig.cmake
  @ONLY
  )

# install the CMake config files

install( FILES
  BUse.cmake
  ${CMAKE_BINARY_DIR}/InstallFiles/BConfig.cmake
  ${CMAKE_BINARY_DIR}/BBuildSettings.cmake
  DESTINATION share/cmake/B
  COMPONENT dev
  )

# install the BLibraryDepends.cmake file

install( EXPORT BLibraryDepends
  DESTINATION share/cmake/B
  NAMESPACE B_
  COMPONENT dev
  )
--8--


And then, in your A/CMakeLists.txt you do the following to use B:

A/CMakeLists.txt:
--8--

find_package(B REQUIRED)
include(${B_USE_FILE})

add_executable(a asrc1.c asrc2.c asrc3.c)
target_link_libraries(a B_b1 B_b2)

--8--

In order for CMake to find the BConfig.cmake, it searches some known  
system directories (refer to the documentation of find_package). If  
CMake can't find the 

Re: [CMake] add_subdirectory and build directory

2009-09-11 Thread Marcel Loose
Hi Pierre-Julien,

Are you sure it's rebuilding? CMake (or 'make' actually), prints a lot
of messages Built target ... even if no compilation was needed.
However, if you also see messages like Building ... then it is
actually rebuilding.

Without an example of the output of your build, it is hard to judge
what, if anything, is going wrong.

Best regards,
Marcel Loose.

On Fri, 2009-09-11 at 15:12 +0200, Pierre-Julien Villoud wrote:
 Hi everyone, 
 
  
 
 After unsuccessfully looking for an answer on Google, I contact you.
 
 I have a question regarding the use of add_subdirectory. When a
 project A is depending on a project B, I add the following in A’s
 CMakeLists.txt : 
 
  
 
 Add_subdirectory(B Path/To/B/Build/Directory)
 
  
 
 It does build B before A. But when I build B in its build directory
 and I build A after, it builds B again whereas it should not since B
 is up to date.
 
  
 
 Anyone sees what’s wrong ?
 
  
 
 Thanks in advance
 
  
 
 Pierre-Julien VILLOUD
 
 
 ___
 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


Re: [CMake] Make project name a target

2009-09-11 Thread Jeroen Dierckx
On Fri, Sep 11, 2009 at 4:22 PM, Marcel Loose lo...@astron.nl wrote:
 Hi David,

 I don't see the exact difference between (1) and (2). And yes, I was
 thinking of using the project name as a target. You are right, that it
 might cause clashes with existing projects, though :-(

 We use the convention that project names are always capitalized, so we
 usually don't run into problems.

 Is there a nifty trick to wrap the 'project' command? I never succeeded
 in doing that.

I did this once inside a macro, and that should work as expected. The
code of the macro should behave just as if it was copy-pasted to the
place where you call the macro, so scope and such will be that of the
place where you call it.

Greetings,
JeDi



 Best regards,
 Marcel Loose.


 On Fri, 2009-09-11 at 07:09 -0400, David Cole wrote:
 When you say make the project name a target what do you mean by
 that?


 (1) internally create a CMake target with the given name?
 (2) create a makefile target with that name that builds all the cmake
 targets in that cmake project?
 (3) something else?


 (1) is probably not feasible for most folks -- because many people use
 the same name for their PROJECT statement and the main library or
 executable for that project which is already a cmake target (and a
 makefile target) with that name.



 On Fri, Sep 11, 2009 at 3:51 AM, Marcel Loose lo...@astron.nl wrote:
         Hi all,

         I was wondering whether it's a good idea to make the project
         name (i.e.
         the argument to the 'project' command) a target.

         Rationale: I have a project that consists of numerous
         sub-projects and I
         would like to be able to build some of these separately.
         Wrapping the
         'project' command in a macro is not a solution, because AFAIK
         CMake
         *must* see a 'project' command in the top-level CMakeLists.txt
         file; a
         'myproject' macro, wrapping the 'project' command, will not
         do.

         Any comments?

         Best regards,
         Marcel Loose.


         ___
         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

___
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] add_subdirectory and build directory

2009-09-11 Thread Bill Hoffman




That's NOT what add_subdirectory is made for. It is intended for adding 
a sub-directory in the source tree. So, if your directory structure 
looks like this (i.e. B is a sub-project of A)


A/CMakeLists.txt
A/B/CMakeLists.txt

things are simple:

A/CMakeLists.txt:


Actually add_subdirectory does support the notion of out-of-source 
source.   So, a source directory in does not have to be a direct 
sub-directory on disk.


-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


[CMake] linking error after upgrading to snow leopard

2009-09-11 Thread Boudewijn Rempt
Hi,

I'm getting weird linking errors after I upgraded to Snow Leopard. I'm using
the CVS version of cmake. If I have the MACOSX_BUNDLE flag in ADD_EXECUTABLE,
there are lots of weird visiblity errors like:
nking CXX executable HyvesDesktop.app/Contents/MacOS/HyvesDesktop
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/HyvesDesktop.dir/link.txt 
--verbose=1
/usr/bin/c++-mmacosx-version-min=10.6 -Wall -arch i386 -fPIC 
-fvisibility=hidden -fvisibility-inlines-hidden -Wl,-search_paths_first 
-headerpad_max_install_names -fPIC 
CMakeFiles/HyvesDesktop.dir/HyvesDesktop_automoc.cpp.o 
CMakeFiles/HyvesDesktop.dir/src/main.cpp.o 
CMakeFiles/HyvesDesktop.dir/qrc_HyvesDesktop.cxx.o  -o 
HyvesDesktop.app/Contents/MacOS/HyvesDesktop  
Undefined symbols:
  CrashHandler::CrashHandler::~CrashHandler(), referenced from:
  _main in main.cpp.o
  _main in main.cpp.o
  QString::free(QString::Data*), referenced from:
  QString::~QString()in main.cpp.o
  Updater::Updater::instance(), referenced from:
  _main in main.cpp.o
  Player::Player::playSound(QString const), referenced from:
  _main in main.cpp.o
  QTextStream::operator(QString const), referenced from:
  _main in main.cpp.o
  _main in main.cpp.o
  _main in main.cpp.o
  Updater::Updater::installAvailableUpdate(), referenced from:
  _main in main.cpp.o
  QTextStream::QTextStream(__sFILE*, QFlagsQIODevice::OpenModeFlag), 
referenced from:
  __static_initialization_and_destruction_0(int, int)in main.cpp.o
  QFileInfo::path() const, referenced from:
  setupLibraryPaths(char**) in main.cpp.o
  endl(QTextStream), referenced from:
  __Z4endlR11QTextStream$non_lazy_ptr in main.cpp.o
  QListData::append(), referenced from:
  QListQString::append(QString const)in main.cpp.o
  Player::Player::instance(), referenced from:
  _main in main.cpp.o
  QCoreApplication::setLibraryPaths(QStringList const), referenced from:
  setupLibraryPaths(char**) in main.cpp.o
  Version::Version(QString const), referenced from:
  __static_initialization_and_destruction_0(int, int)in main.cpp.o
  CrashHandler::CrashHandler::CrashHandler(), referenced from:
  _main in main.cpp.o
  qt_assert(char const*, char const*, int), referenced from:
  QString::QString(QString const)in main.cpp.o
  QtPrivate::QStringList_contains(QStringList const*, QString const, 
Qt::CaseSensitivity), referenced from:
  QStringList::contains(QString const, Qt::CaseSensitivity) constin 
main.cpp.o
  qFree(void*), referenced from:
  QListQString::free(QListData::Data*)   in main.cpp.o
  QListQString::detach_helper()   in main.cpp.o
  QTextStream::operator(char const*), referenced from:
  _main in main.cpp.o
  _main in main.cpp.o
  QListData::shared_null, referenced from:
  __ZN9QListData11shared_nullE$non_lazy_ptr in main.cpp.o
  QTextStream::~QTextStream(), referenced from:
  ___tcf_8 in main.cpp.o
  QDesktopServices::storageLocation(QDesktopServices::StandardLocation), 
referenced from:
  _main in main.cpp.o
  QString::operator=(QString const), referenced from:
  _main in main.cpp.o
  qUnregisterResourceData(int, unsigned char const*, unsigned char const*, 
unsigned char const*), referenced from:
  qCleanupResources_HyvesDesktop() in qrc_HyvesDesktop.cxx.o
  QFileInfo::~QFileInfo(), referenced from:
  setupLibraryPaths(char**) in main.cpp.o
  setupLibraryPaths(char**) in main.cpp.o
  QListData::detach3(), referenced from:
  QListQString::detach_helper()   in main.cpp.o
  QString::fromAscii_helper(char const*, int), referenced from:
  QString::QString(char const*)in main.cpp.o
  Version::toString() const, referenced from:
  _main in main.cpp.o
  _main in main.cpp.o
  QApplication::exec(), referenced from:
  _main in main.cpp.o
  QCoreApplication::arguments(), referenced from:
  _main in main.cpp.o
  QString::fromAscii(char const*, int), referenced from:
  operator+(char const*, QString const)in main.cpp.o
  QString::operator+=(char const*)in main.cpp.o
  operator+(QString const, char const*)in main.cpp.o
  HyvesDesktopApplication::HyvesDesktopApplication(int, char**, QString 
const), referenced from:
  _main in main.cpp.o
  QFileInfo::QFileInfo(QString const), referenced from:
  setupLibraryPaths(char**) in main.cpp.o
  qRegisterResourceData(int, unsigned char const*, unsigned char const*, 
unsigned char const*), referenced from:
  qInitResources_HyvesDesktop() in qrc_HyvesDesktop.cxx.o
  QString::append(QString const), referenced from:
  QString::operator+=(QString const)in main.cpp.o
  QString::operator+=(char const*)in main.cpp.o
  QString::replace(QString const, QString const, Qt::CaseSensitivity), 
referenced from:
  _main in main.cpp.o
  _main in main.cpp.o
  _main in main.cpp.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Does anyone have any hint for me?

Boudewijn


[CMake] Option dependencies

2009-09-11 Thread Jeroen Dierckx
Hi,

We have a rather complex framework that we are converting to cmake. I
want to present the user with options to build some parts of our
framework or not. A lot of these options depend on others (when
building the Ogre rendering modules for example, our engine needs to
be built too).
I know I can use cmake_dependent_option, but this makes things too
confusing for the users (the ones building the framework I mean). In
that case, they first would have to enable building the engine before
they are presented with the option to build the Ogre targets, an
option which they can enable only then.

What I would want is that all these options are presented to the user,
but when they enable building the Ogre targets, the engine option is
automatically checked too. I can do this with the set function using
FORCE, but then I have to declare the whole variable again (with its
type and description). So what I would want is to force an existing
variable to ON, reflecting the change in the cmake GUI (so changing
the cached variable), but withouth having to declare it again.

Ideally I would be able to do the following:

if (NVE_BUILD_OGRE_TARGETS)
  # Force the existing cached variable to ON
  set (NVE_BUILD_ENGINE ON CACHE FORCE)
endif ()

I tried getting the description from an existing variable, but that
didn't work. I used the following code, which gave me a NOT-FOUND:

get_property (DESC VARIABLE PROPERTY NVE_BUILD_ENGINE BRIEF_DOCS)

I also tried FULL_DOCS, without succes.

Greetings,
JeDi
___
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] add_subdirectory and build directory

2009-09-11 Thread Pierre-Julien Villoud
Hi and thanks for your answer...

Here is the ouput : 

I'm building A : My CMakelists.txt is in C:/A

-- Configuring done
-- Generating done
-- Build files have been written to: C:/A/Debug
==Building A==
[  0%] Built target CMake
Scanning dependencies of target B
[  4%] Building CXX object C:/B/CMakeFiles/B.dir/B.cpp.obj
Linking CXX static library C:\lib\libB.a
[  4%] Built target B
Linking CXX shared module C:\bin\A.dll
[100%] Built target A

Then I'm building B : My CMakeLists.txt is in C:/B

-- Configuring done
-- Generating done
-- Build files have been written to: C:/B/Debug
==Building B==
[  0%] Built target CMake
Scanning dependencies of target B
[100%] Building CXX object CMakeFiles/B.dir/B.cpp.obj
Linking CXX static library C:\lib\libB.a
[100%] Built target B


Any clues ?

@Michael : I did not look at your long and precise answer (thank you very much 
for it BTW) but it seems quite complicated !! How are you managing your 
dependencies ?

Thank you for your help !



-Message d'origine-
De : Marcel Loose [mailto:lo...@astron.nl] 
Envoyé : vendredi 11 septembre 2009 16:30
À : Pierre-Julien Villoud
Cc : cmake@cmake.org
Objet : Re: [CMake] add_subdirectory and build directory

Hi Pierre-Julien,

Are you sure it's rebuilding? CMake (or 'make' actually), prints a lot
of messages Built target ... even if no compilation was needed.
However, if you also see messages like Building ... then it is
actually rebuilding.

Without an example of the output of your build, it is hard to judge
what, if anything, is going wrong.

Best regards,
Marcel Loose.

On Fri, 2009-09-11 at 15:12 +0200, Pierre-Julien Villoud wrote:
 Hi everyone, 
 
  
 
 After unsuccessfully looking for an answer on Google, I contact you.
 
 I have a question regarding the use of add_subdirectory. When a
 project A is depending on a project B, I add the following in A's
 CMakeLists.txt : 
 
  
 
 Add_subdirectory(B Path/To/B/Build/Directory)
 
  
 
 It does build B before A. But when I build B in its build directory
 and I build A after, it builds B again whereas it should not since B
 is up to date.
 
  
 
 Anyone sees what's wrong ?
 
  
 
 Thanks in advance
 
  
 
 Pierre-Julien VILLOUD
 
 
 ___
 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


Re: [CMake] linking error after upgrading to snow leopard

2009-09-11 Thread James C. Sutherland

On Sep 11, 2009, at 8:24 AM, Boudewijn Rempt wrote:


I'm getting weird linking errors after I upgraded to Snow Leopard.


This is probably because the library you are linking to is 32-bit and  
Snow Leopard's development environment will produce 64-bit binaries.


Try recompiling the library/libraries you are linking against.
___
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] add_subdirectory and build directory

2009-09-11 Thread Marcel Loose
Hi Pierre-Julien,

I think I see what the problem is. You didn't specify any dependencies.
You mention that project A depends on B. But don't you actually mean
that libA depends on libB? If that's the case you should add a
target_link_libraries(libA libB) to the CMakeLists.txt file of project
A.

Anyway, you may want to post your CMakeLists.txt files, so that people
can spot what you might be doing wrong. At the moment, I can only make
some wild guesses.

Best regards,
Marcel Loose.

On Fri, 2009-09-11 at 17:34 +0200, Pierre-Julien Villoud wrote:
 Hi and thanks for your answer...
 
 Here is the ouput : 
 
 I'm building A : My CMakelists.txt is in C:/A
 
 -- Configuring done
 -- Generating done
 -- Build files have been written to: C:/A/Debug
 ==Building A==
 [  0%] Built target CMake
 Scanning dependencies of target B
 [  4%] Building CXX object C:/B/CMakeFiles/B.dir/B.cpp.obj
 Linking CXX static library C:\lib\libB.a
 [  4%] Built target B
 Linking CXX shared module C:\bin\A.dll
 [100%] Built target A
 
 Then I'm building B : My CMakeLists.txt is in C:/B
 
 -- Configuring done
 -- Generating done
 -- Build files have been written to: C:/B/Debug
 ==Building B==
 [  0%] Built target CMake
 Scanning dependencies of target B
 [100%] Building CXX object CMakeFiles/B.dir/B.cpp.obj
 Linking CXX static library C:\lib\libB.a
 [100%] Built target B
 
 
 Any clues ?
 
 @Michael : I did not look at your long and precise answer (thank you very 
 much for it BTW) but it seems quite complicated !! How are you managing your 
 dependencies ?
 
 Thank you for your help !
 
 
 
 -Message d'origine-
 De : Marcel Loose [mailto:lo...@astron.nl] 
 Envoyé : vendredi 11 septembre 2009 16:30
 À : Pierre-Julien Villoud
 Cc : cmake@cmake.org
 Objet : Re: [CMake] add_subdirectory and build directory
 
 Hi Pierre-Julien,
 
 Are you sure it's rebuilding? CMake (or 'make' actually), prints a lot
 of messages Built target ... even if no compilation was needed.
 However, if you also see messages like Building ... then it is
 actually rebuilding.
 
 Without an example of the output of your build, it is hard to judge
 what, if anything, is going wrong.
 
 Best regards,
 Marcel Loose.
 
 On Fri, 2009-09-11 at 15:12 +0200, Pierre-Julien Villoud wrote:
  Hi everyone, 
  
   
  
  After unsuccessfully looking for an answer on Google, I contact you.
  
  I have a question regarding the use of add_subdirectory. When a
  project A is depending on a project B, I add the following in A's
  CMakeLists.txt : 
  
   
  
  Add_subdirectory(B Path/To/B/Build/Directory)
  
   
  
  It does build B before A. But when I build B in its build directory
  and I build A after, it builds B again whereas it should not since B
  is up to date.
  
   
  
  Anyone sees what's wrong ?
  
   
  
  Thanks in advance
  
   
  
  Pierre-Julien VILLOUD
  
  
  ___
  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

___
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] Make project name a target

2009-09-11 Thread Alexander Neundorf
On Friday 11 September 2009, David Cole wrote:
 When you say make the project name a target what do you mean by that?
 (1) internally create a CMake target with the given name?
 (2) create a makefile target with that name that builds all the cmake
 targets in that cmake project?

I think this should be more or less the same as invoking make without specific 
target in project_BINARY_DIR.

Alex
___
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] linking error after upgrading to snow leopard

2009-09-11 Thread Boudewijn Rempt
On Friday 11 September 2009, James C. Sutherland wrote:
 On Sep 11, 2009, at 8:24 AM, Boudewijn Rempt wrote:
  I'm getting weird linking errors after I upgraded to Snow Leopard.
 
 This is probably because the library you are linking to is 32-bit and
 Snow Leopard's development environment will produce 64-bit binaries.
 
 Try recompiling the library/libraries you are linking against.

That's why I specified -arch i386 -- and if I don't do that, Qt tells me it's 
32 bits and I'm trying to build a 64 bit app.

-- 
Boudewijn Rempt | http://www.valdyas.org
___
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] linking error after upgrading to snow leopard

2009-09-11 Thread Sean McBride
On 9/11/09 4:24 PM, Boudewijn Rempt said:

I'm getting weird linking errors after I upgraded to Snow Leopard. I'm using
the CVS version of cmake. If I have the MACOSX_BUNDLE flag in ADD_EXECUTABLE,
there are lots of weird visiblity errors like:
nking CXX executable HyvesDesktop.app/Contents/MacOS/HyvesDesktop
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/HyvesDesktop.dir/
link.txt --verbose=1
/usr/bin/c++-mmacosx-version-min=10.6 -Wall -arch i386 -fPIC -
fvisibility=hidden -fvisibility-inlines-hidden -Wl,-search_paths_first -
headerpad_max_install_names -fPIC CMakeFiles/HyvesDesktop.dir/
HyvesDesktop_automoc.cpp.o CMakeFiles/HyvesDesktop.dir/src/main.cpp.o
CMakeFiles/HyvesDesktop.dir/qrc_HyvesDesktop.cxx.o  -o HyvesDesktop.app/
Contents/MacOS/HyvesDesktop  
Undefined symbols:
  CrashHandler::CrashHandler::~CrashHandler(), referenced from:
  _main in main.cpp.o
  _main in main.cpp.o
  QString::free(QString::Data*), referenced from:
  QString::~QString()in main.cpp.o
  Updater::Updater::instance(), referenced from:
  _main in main.cpp.o

Are all those symbols from some library/framework you are linking
against?  Qt I assume?

Was Qt built with the same compiler and deployment target as your app?

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


___
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] linking error after upgrading to snow leopard

2009-09-11 Thread James C. Sutherland


On Sep 11, 2009, at 12:16 PM, Boudewijn Rempt wrote:


On Friday 11 September 2009, James C. Sutherland wrote:

On Sep 11, 2009, at 8:24 AM, Boudewijn Rempt wrote:

I'm getting weird linking errors after I upgraded to Snow Leopard.


This is probably because the library you are linking to is 32-bit and
Snow Leopard's development environment will produce 64-bit binaries.

Try recompiling the library/libraries you are linking against.


That's why I specified -arch i386 -- and if I don't do that, Qt  
tells me it's

32 bits and I'm trying to build a 64 bit app.

You may look at a recent thread on this topic (very active last  
week).  I deleted it, but as I recall there was some discussion about  
CMake not handling this properly...

___
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] linking error after upgrading to snow leopard

2009-09-11 Thread S Roderick

On Sep 11, 2009, at 14:27 , Sean McBride wrote:


On 9/11/09 4:24 PM, Boudewijn Rempt said:

I'm getting weird linking errors after I upgraded to Snow Leopard.  
I'm using
the CVS version of cmake. If I have the MACOSX_BUNDLE flag in  
ADD_EXECUTABLE,

there are lots of weird visiblity errors like:
nking CXX executable HyvesDesktop.app/Contents/MacOS/HyvesDesktop
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/ 
HyvesDesktop.dir/

link.txt --verbose=1
/usr/bin/c++-mmacosx-version-min=10.6 -Wall -arch i386 -fPIC -
fvisibility=hidden -fvisibility-inlines-hidden -Wl,- 
search_paths_first -

headerpad_max_install_names -fPIC CMakeFiles/HyvesDesktop.dir/
HyvesDesktop_automoc.cpp.o CMakeFiles/HyvesDesktop.dir/src/main.cpp.o
CMakeFiles/HyvesDesktop.dir/qrc_HyvesDesktop.cxx.o  -o  
HyvesDesktop.app/

Contents/MacOS/HyvesDesktop
Undefined symbols:
CrashHandler::CrashHandler::~CrashHandler(), referenced from:
_main in main.cpp.o
_main in main.cpp.o
QString::free(QString::Data*), referenced from:
QString::~QString()in main.cpp.o
Updater::Updater::instance(), referenced from:
_main in main.cpp.o


Are all those symbols from some library/framework you are linking
against?  Qt I assume?


Do you need to explicitly list the Qt libraries to link against, in  
the above link command line?

Stephen

___
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] Only install file if it does not exist?

2009-09-11 Thread Bob Tanner
On 2009-09-10 01:12:43 -0500, Eric Noulard 
eric.noul...@gmail.com said:



0)  Write your parameterized  CMake script CopyIfNotExists.cmake.in

1)  CONFIGURE_FILE(CopyIfNotExists.cmake.in CopyIfNotExists.cmake)
 This step will replace appropriate vars in CopyIfNotExists.cmake.in
 with value coming from your current config.

2)  INSTALL(SCRIPT CopyIfNotExists.cmake)


Thank you for your help!

I tried this approach.

CMakeLists.txt

INSTALL (SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/CopyIfNotExists.cmake)

CopyIfNotExists.cmake

MACRO (COPY_IF_NOT_EXISTS _SRC _DEST)
	MESSAGE (Copy ${CMAKE_CURRENT_SOURCE_DIR}/${_SRC} to 
${CMAKE_INSTALL_PREFIX}/${_DEST})

IF (NOT EXISTS ${CMAKE_INSTALL_PREFIX}/${_DEST})
		EXECUTE_PROCESS (COMMAND ${CMAKE_COMMAND} -E copy 
${CMAKE_CURRENT_SOURCE_DIR}/${_SRC}
 
${CMAKE_INSTALL_PREFIX}/${_DEST})

ENDIF (NOT EXISTS ${CMAKE_INSTALL_PREFIX}/${_DEST})
ENDMACRO (COPY_IF_NOT_EXISTS _SRC _DEST)

COPY_IF_NOT_EXISTS (sample_features etc/features)

The problem is ${CMAKE_CURRENT_SOURCE_DIR} is set to the out-of-source 
build directory.


Is this why you said to use a parameterized  cmake script?

--
Bob Tanner tan...@real-time.com  | Phone : (952 943-8700
http://www.real-time.com, Linux, OSX, VMware | Fax   : (952)943-8500
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378


___
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] Only install file if it does not exist?

2009-09-11 Thread Eric Noulard
2009/9/11 Bob Tanner tan...@real-time.com:
 On 2009-09-10 01:12:43 -0500, Eric Noulard eric.noul...@gmail.com said:

 0)  Write your parameterized  CMake script CopyIfNotExists.cmake.in

 1)  CONFIGURE_FILE(CopyIfNotExists.cmake.in CopyIfNotExists.cmake)
     This step will replace appropriate vars in CopyIfNotExists.cmake.in
     with value coming from your current config.

 2)  INSTALL(SCRIPT CopyIfNotExists.cmake)

 Thank you for your help!

 I tried this approach.

 CMakeLists.txt

 INSTALL (SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/CopyIfNotExists.cmake)

 CopyIfNotExists.cmake

 MACRO (COPY_IF_NOT_EXISTS _SRC _DEST)
        MESSAGE (Copy ${CMAKE_CURRENT_SOURCE_DIR}/${_SRC} to
 ${CMAKE_INSTALL_PREFIX}/${_DEST})
        IF (NOT EXISTS ${CMAKE_INSTALL_PREFIX}/${_DEST})
                EXECUTE_PROCESS (COMMAND ${CMAKE_COMMAND} -E copy
 ${CMAKE_CURRENT_SOURCE_DIR}/${_SRC}

 ${CMAKE_INSTALL_PREFIX}/${_DEST})
        ENDIF (NOT EXISTS ${CMAKE_INSTALL_PREFIX}/${_DEST})
 ENDMACRO (COPY_IF_NOT_EXISTS _SRC _DEST)

 COPY_IF_NOT_EXISTS (sample_features etc/features)

 The problem is ${CMAKE_CURRENT_SOURCE_DIR} is set to the out-of-source build
 directory.

 Is this why you said to use a parameterized  cmake script?

Yes you are right.
Most (if not all) variable you expect to use are not defined when
CopyIfNotExists.cmake is invoked.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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


[CMake] Eclipse CDT4 generator - No source files

2009-09-11 Thread Dixon, Shane
I'm generating an eclipse project and whenever I import the project, all the 
files are there except for the source and header files.  I had a similar 
problem when generating Visual Studio 9 2008 projects ( I was missing the 
header files).  I fixed that by adding all the .h files to my project_SRCS 
variable so that they all now show up in VS9, but how do I get this to show up 
in Eclipse?  My build platform is Windows XP SP3.

 

 

--

Shane Dixon

Linux Engineer

___
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] Make project name a target

2009-09-11 Thread Marcel Loose
Hi JeDi,

If you look carefully, you will notice that, when you create a project
through a macro (e.g. myproject), CMake will create a dummy project
named Project and assume you're using C and C++ as default languages.

Note that I intentionally chose a non-supported language, CPP, in the
example below. Look at the line printing PROJECT_NAME. But you'll notice
a significant difference in output anyway.

Best regards,
Marcel Loose.


CMakeLists.txt with direct call of project() command:

$ pwd
/home/loose/work/cmake/build

$ cat ../proj/CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
message(STATUS PROJECT_NAME = ${PROJECT_NAME})
project(main CPP)

$ cmake -DCMAKE_MODULE_PATH:PATH=$HOME/work/cmake/proj ../proj
-- PROJECT_NAME = 
CMake Error: Error required internal CMake variable not set, cmake may
be not be built correctly.
Missing variable is:
CMAKE_CPP_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may
be not be built correctly.
Missing variable is:
CMAKE_CPP_COMPILER
CMake Error: Could not find cmake module
file:/home/loose/work/cmake/build/CMakeFiles/CMakeCPPCompiler.cmake
CMake Error: Could not find cmake module file:CMakeCPPInformation.cmake
CMake Error: CMAKE_CPP_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!


CMakeLists.txt with call of project() through myproject macro:
-
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
message(STATUS PROJECT_NAME = ${PROJECT_NAME})
include(myproject)
myproject(main CPP)

$ cmake -DCMAKE_MODULE_PATH:PATH=$HOME/work/cmake/proj ../proj
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- PROJECT_NAME = Project
CMake Error: Error required internal CMake variable not set, cmake may
be not be built correctly.
Missing variable is:
CMAKE_CPP_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may
be not be built correctly.
Missing variable is:
CMAKE_CPP_COMPILER
CMake Error: Could not find cmake module
file:/home/loose/work/cmake/build/CMakeFiles/CMakeCPPCompiler.cmake
CMake Error: Could not find cmake module file:CMakeCPPInformation.cmake
CMake Error: CMAKE_CPP_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!

On Fri, 2009-09-11 at 16:34 +0200, Jeroen Dierckx wrote:
 On Fri, Sep 11, 2009 at 4:22 PM, Marcel Loose lo...@astron.nl wrote:
  Hi David,
 
  I don't see the exact difference between (1) and (2). And yes, I was
  thinking of using the project name as a target. You are right, that it
  might cause clashes with existing projects, though :-(
 
  We use the convention that project names are always capitalized, so we
  usually don't run into problems.
 
  Is there a nifty trick to wrap the 'project' command? I never succeeded
  in doing that.
 
 I did this once inside a macro, and that should work as expected. The
 code of the macro should behave just as if it was copy-pasted to the
 place where you call the macro, so scope and such will be that of the
 place where you call it.
 
 Greetings,
 JeDi
 
 
 
  Best regards,
  Marcel Loose.
 
 
  On Fri, 2009-09-11 at 07:09 -0400, David Cole wrote:
  When you say make the project name a target what do you mean by
  that?
 
 
  (1) internally create a CMake target with the given name?
  (2) create a makefile target with that name that builds all the cmake
  targets in that cmake project?
  (3) something else?
 
 
  (1) is probably not feasible for most folks -- because many people use
  the same name for their PROJECT statement and the main library or
  executable for that project which is already a cmake target (and a
  makefile target) with that name.
 
 
 
  On Fri, Sep 11, 2009 at 3:51 AM, Marcel Loose lo...@astron.nl wrote:
  Hi all,
 
  I was wondering whether it's a good idea to make the project
  name (i.e.
  the argument to the 'project' command) a target.
 
  Rationale: I have a project that consists of numerous
  sub-projects and I
  would like to be able to build some of these separately.
  Wrapping the
  'project' command in a macro is not a solution, because AFAIK
  CMake
  *must* see a 'project' command in the top-level CMakeLists.txt
  file; a
  'myproject' macro, wrapping the 'project' command, will not
  do.
 
  Any comments?
 
  Best regards,
  Marcel Loose.
 
 
  ___