Re: [CMake] cmake and sun workshop compiler.
George Neill wrote: Hi CMakers, I'd like to use cmake with the Sun cc/CC compiler on linux. What do I need to change to make this work? Put them in your PATH. Then set CC=cc, CXX=CC and run cmake. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Win: Dependency for def file missing
Hi all,
I am generating a DLL under Windows using a def file. The def file
itself is generated. It seems that CMake (2.6.3rc5) does not generate a
dependency between the generated def file and the DLL. When I change the
input, from which the def file is generated, the def file is rebuilt,
but not the DLL itself. The code looks as follows:
SET(DefFile ${CMAKE_CURRENT_BINARY_DIR}/FortranInterface.def)
ADD_CUSTOM_COMMAND(OUTPUT ${DefFile}
COMMAND ${PERL_EXECUTABLE}
${CMAKE_SOURCE_DIR}/scripts/create_dll_exports_file.pl
--export-file=${DefFile} --so-name=FortranInterface
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
)
ADD_LIBRARY(FortranInterface SHARED ${DefFile} ${FortranSrc})
TARGET_LINK_LIBRARIES(FortranInterface ${MY_LIBS})
SET_TARGET_PROPERTIES(FortranInterface PROPERTIES
LINK_INTERFACE_LIBRARIES )
SET_SOURCE_FILES_PROPERTIES(${DefFile} PROPERTIES GENERATED 1)
To me this looks like a bug in CMake. Can somebody confirm, that this is
a bug or am I doing something wrong?
Regards,
Martin
Virus checked by G DATA AntiVirus
Version: AVF 19.178 from 08.12.2008
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Search paths for FooConfig.cmake files
Hello CMake developers!
I've been thinking it would be interesting that CMake could look for
FooConfig.cmake package files in some likely paths such as C:\Program
Files\Foo-XXX\ . This is for Windows, of course, but perhaps could be
extended to /opt/foo-XXX/ in Unix systems.
I've written a patch for this task:
http://public.kitware.com/Bug/view.php?id=8264
I know the order in which directories are searched IS an issue, and I
decided it's place seems to be between these two paths:
=
...
4. Search the standard system environment variables. This can be skipped
if NO_SYSTEM_ENVIRONMENT_PATH is passed. Path entries ending in /bin
or /sbin are automatically converted to their parent directories.
PATH
5. Typical instalation paths. For now this only applies to Windowsfor
the paths that match the following pattern (where name iscase
insensitive):
${ProgramFiles}/name* (W)
6. Search project build trees recently configured in a CMake GUI. This
can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the
case when a user is building multiple dependent projects one after another.
...
=
I'd be glad of seeing this feature in future releases of CMake, so
please let me know if anyone see any compatibility problem in this patch
and how to deal with it.
Best,
JL
--
___
Jose-Luis Blanco-Claraco Phone: +34 952 132848
Dpto. Ingenieria de Sistemas y Automatica
E.T.S.I. Telecomunicacion Fax: +34 952 133361
Universidad de Malaga
Campus Universitario de Teatinos
29071 Malaga, Spain
http://www.isa.uma.es/jlblanco
___
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6.3 RC 5
Brad King wrote: Alexander Neundorf wrote: So, I think it would be nice if find_package(NO_MODULE) would restore the FIND_QUIETLY variable to the state it was before (as I'm doing here manually). Good idea. I don't think we make any guarantee either way about the value of this variable *after* a call, but we do document how it is set *inside* the find-module (which is the case after the call in your example), so we should preserve it. I've added this to my todo-list. Fortunately fixing it won't break your work-around. Done. Please try it from CVS HEAD. -Brad /cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v -- Source/cmFindPackageCommand.cxx new revision: 1.50; previous revision: 1.49 /cvsroot/CMake/CMake/Source/cmFindPackageCommand.h,v -- Source/cmFindPackageCommand.h new revision: 1.26; previous revision: 1.25 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Win: Dependency for def file missing
Martin Apel wrote:
Hi all,
I am generating a DLL under Windows using a def file. The def file
itself is generated. It seems that CMake (2.6.3rc5) does not generate a
dependency between the generated def file and the DLL. When I change the
input, from which the def file is generated, the def file is rebuilt,
but not the DLL itself. The code looks as follows:
SET(DefFile ${CMAKE_CURRENT_BINARY_DIR}/FortranInterface.def)
ADD_CUSTOM_COMMAND(OUTPUT ${DefFile}
COMMAND ${PERL_EXECUTABLE}
${CMAKE_SOURCE_DIR}/scripts/create_dll_exports_file.pl
--export-file=${DefFile} --so-name=FortranInterface
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
)
ADD_LIBRARY(FortranInterface SHARED ${DefFile} ${FortranSrc})
TARGET_LINK_LIBRARIES(FortranInterface ${MY_LIBS})
SET_TARGET_PROPERTIES(FortranInterface PROPERTIES
LINK_INTERFACE_LIBRARIES )
SET_SOURCE_FILES_PROPERTIES(${DefFile} PROPERTIES GENERATED 1)
To me this looks like a bug in CMake. Can somebody confirm, that this is
a bug or am I doing something wrong?
What version of VS are you using? Also, nmake or VS IDE?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Search paths for FooConfig.cmake files
Jose Luis Blanco wrote:
Hello CMake developers!
I've been thinking it would be interesting that CMake could look for
FooConfig.cmake package files in some likely paths such as C:\Program
Files\Foo-XXX\ . This is for Windows, of course, but perhaps could be
extended to /opt/foo-XXX/ in Unix systems.
I've written a patch for this task:
http://public.kitware.com/Bug/view.php?id=8264
I know the order in which directories are searched IS an issue, and I
decided it's place seems to be between these two paths:
=
...
4. Search the standard system environment variables. This can be skipped
if NO_SYSTEM_ENVIRONMENT_PATH is passed. Path entries ending in /bin
or /sbin are automatically converted to their parent directories.
PATH
5. Typical instalation paths. For now this only applies to Windowsfor
the paths that match the following pattern (where name iscase
insensitive):
${ProgramFiles}/name* (W)
6. Search project build trees recently configured in a CMake GUI. This
can be skipped if NO_CMAKE_BUILDS_PATH is passed. It is intended for the
case when a user is building multiple dependent projects one after another.
...
=
I'd be glad of seeing this feature in future releases of CMake, so
please let me know if anyone see any compatibility problem in this patch
and how to deal with it.
Thanks for the patch. Looking in ProgramFiles has been on my todo list
for this command for a while. I'll look at your patch when I get a chance.
Thanks,
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake and sun workshop compiler.
Bill, On Tue, Dec 9, 2008 at 7:02 AM, Bill Hoffman [EMAIL PROTECTED] wrote: George Neill wrote: Hi CMakers, I'd like to use cmake with the Sun cc/CC compiler on linux. What do I need to change to make this work? Put them in your PATH. Then set CC=cc, CXX=CC and run cmake. It looks like it's picking up the gcc/g++ flags. [EMAIL PROTECTED]:~/test$ cat CMakeLists.txt PROJECT(test) ADD_EXECUTABLE(test1 t.c) ADD_EXECUTABLE(test2 t.cpp) [EMAIL PROTECTED]:~/test$ cmake . -- Check for working C compiler: /home/gneill/Desktop/sse/sunstudioceres/bin/cc -- Check for working C compiler: /home/gneill/Desktop/sse/sunstudioceres/bin/cc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /home/gneill/Desktop/sse/sunstudioceres/bin/CC -- Check for working CXX compiler: /home/gneill/Desktop/sse/sunstudioceres/bin/CC -- broken CMake Error: The C++ compiler /home/gneill/Desktop/sse/sunstudioceres/bin/CC is not able to compile a simple test program. It fails with the following output: /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build make[1]: Entering directory `/home/gneill/test/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /home/gneill/test/CMakeFiles/CMakeTmp/CMakeFiles 1 Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.o /home/gneill/Desktop/sse/sunstudioceres/bin/CC-o CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.o -c /home/gneill/test/CMakeFiles/CMakeTmp/testCXXCompiler.cxx Linking CXX executable cmTryCompileExec /usr/bin/cmake -P CMakeFiles/cmTryCompileExec.dir/cmake_clean_target.cmake /home/gneill/Desktop/sse/sunstudioceres/bin/CC -fPIC CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.o -o cmTryCompileExec -rdynamic CC: Warning: Option -fPIC passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -rdynamic passed to ld, if ld is invoked, ignored otherwise /home/gneill/Desktop/sse/sunstudioceres/prod/lib/ld: bad -rpath option make[1]: *** [cmTryCompileExec] Error 1 make[1]: Leaving directory `/home/gneill/test/CMakeFiles/CMakeTmp' make: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done TIA, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Win: Dependency for def file missing
Bill Hoffman wrote:
Martin Apel wrote:
Hi all,
I am generating a DLL under Windows using a def file. The def file
itself is generated. It seems that CMake (2.6.3rc5) does not generate a
dependency between the generated def file and the DLL. When I change the
input, from which the def file is generated, the def file is rebuilt,
but not the DLL itself. The code looks as follows:
SET(DefFile ${CMAKE_CURRENT_BINARY_DIR}/FortranInterface.def)
ADD_CUSTOM_COMMAND(OUTPUT ${DefFile}
COMMAND ${PERL_EXECUTABLE}
${CMAKE_SOURCE_DIR}/scripts/create_dll_exports_file.pl
--export-file=${DefFile} --so-name=FortranInterface
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
)
ADD_LIBRARY(FortranInterface SHARED ${DefFile} ${FortranSrc})
TARGET_LINK_LIBRARIES(FortranInterface ${MY_LIBS})
SET_TARGET_PROPERTIES(FortranInterface PROPERTIES
LINK_INTERFACE_LIBRARIES )
SET_SOURCE_FILES_PROPERTIES(${DefFile} PROPERTIES GENERATED 1)
To me this looks like a bug in CMake. Can somebody confirm, that this is
a bug or am I doing something wrong?
What version of VS are you using? Also, nmake or VS IDE?
Hi Bill and all the rest,
sorry, I forgot to state this: VS version is 2005 and I am using nmake.
Best Regards,
Martin
--
Martin Apel Tel: 0049 8153 9288-47
Software Architect E-Mail: [EMAIL PROTECTED]
INTEC GmbH Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling E-Mail: [EMAIL PROTECTED]
Germany URL: http://www.simpack.com
Virus checked by G DATA AntiVirus
Version: AVF 19.178 from 08.12.2008
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake and sun workshop compiler.
George Neill wrote: Bill, On Tue, Dec 9, 2008 at 7:02 AM, Bill Hoffman [EMAIL PROTECTED] wrote: George Neill wrote: Hi CMakers, I'd like to use cmake with the Sun cc/CC compiler on linux. What do I need to change to make this work? Put them in your PATH. Then set CC=cc, CXX=CC and run cmake. It looks like it's picking up the gcc/g++ flags. CC: Warning: Option -fPIC passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -rdynamic passed to ld, if ld is invoked, ignored otherwise /home/gneill/Desktop/sse/sunstudioceres/prod/lib/ld: bad -rpath option make[1]: *** [cmTryCompileExec] Error 1 make[1]: Leaving directory `/home/gneill/test/CMakeFiles/CMakeTmp' make: *** [cmTryCompileExec/fast] Error 2 What version of cmake are you using? We have a dashboard with this compiler and it works fine: http://www.cdash.org/CDash/viewNotes.php?buildid=228158 Do you have CXXFLAGS, CFLAGS, or LDFLAGS set in your environment before you run CMake that have gnu flags in them? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Win: Dependency for def file missing
Martin Apel wrote:
Bill Hoffman wrote:
Martin Apel wrote:
Hi all,
I am generating a DLL under Windows using a def file. The def file
itself is generated. It seems that CMake (2.6.3rc5) does not generate a
dependency between the generated def file and the DLL. When I change the
input, from which the def file is generated, the def file is rebuilt,
but not the DLL itself. The code looks as follows:
SET(DefFile ${CMAKE_CURRENT_BINARY_DIR}/FortranInterface.def)
ADD_CUSTOM_COMMAND(OUTPUT ${DefFile}
COMMAND ${PERL_EXECUTABLE}
${CMAKE_SOURCE_DIR}/scripts/create_dll_exports_file.pl
--export-file=${DefFile} --so-name=FortranInterface
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
)
ADD_LIBRARY(FortranInterface SHARED ${DefFile} ${FortranSrc})
TARGET_LINK_LIBRARIES(FortranInterface ${MY_LIBS})
SET_TARGET_PROPERTIES(FortranInterface PROPERTIES
LINK_INTERFACE_LIBRARIES )
SET_SOURCE_FILES_PROPERTIES(${DefFile} PROPERTIES GENERATED 1)
To me this looks like a bug in CMake. Can somebody confirm, that this is
a bug or am I doing something wrong?
What version of VS are you using? Also, nmake or VS IDE?
Hi Bill and all the rest,
sorry, I forgot to state this: VS version is 2005 and I am using nmake.
Can you send me your binary tree (after a make clean) so I can see the
makefiles that were generated? You can send it off the list if you want.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Emulating libtool's -version-info with CMake?
Hi all! I have a .so library (for Unix/Windows) that I maintain several versions of. I'd like to have a symbolic links structure similar to libtool's -version-info : http://www.ensta.fr/~diam/dev/online/autoconf/autobook/autobook_91.html The problem is that when doing ADD_LIBRARY, the resultant .so is just .so with no versions inside. How can I emulate the behaviour of libtool in this regard using CMake? Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ The Case for File Swapping - http://xrl.us/bjn7i Shlomi, so what are you working on? Working on a new wiki about unit testing fortunes in freecell? -- Ran Eilam ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake and sun workshop compiler.
Bill, On Tue, Dec 9, 2008 at 9:43 AM, Bill Hoffman [EMAIL PROTECTED] wrote: George Neill wrote: Bill, On Tue, Dec 9, 2008 at 7:02 AM, Bill Hoffman [EMAIL PROTECTED] wrote: George Neill wrote: Hi CMakers, I'd like to use cmake with the Sun cc/CC compiler on linux. What do I need to change to make this work? Put them in your PATH. Then set CC=cc, CXX=CC and run cmake. It looks like it's picking up the gcc/g++ flags. CC: Warning: Option -fPIC passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -rdynamic passed to ld, if ld is invoked, ignored otherwise /home/gneill/Desktop/sse/sunstudioceres/prod/lib/ld: bad -rpath option make[1]: *** [cmTryCompileExec] Error 1 make[1]: Leaving directory `/home/gneill/test/CMakeFiles/CMakeTmp' make: *** [cmTryCompileExec/fast] Error 2 What version of cmake are you using? We have a dashboard with this compiler and it works fine: http://www.cdash.org/CDash/viewNotes.php?buildid=228158 [EMAIL PROTECTED]:~$ cmake --version cmake version 2.4-patch 7 Do you have CXXFLAGS, CFLAGS, or LDFLAGS set in your environment before you run CMake that have gnu flags in them? I do not, [EMAIL PROTECTED]:~$ env | grep CC [EMAIL PROTECTED]:~$ env | grep CXX [EMAIL PROTECTED]:~$ env | grep LDFLAGS [EMAIL PROTECTED]:~$ I am trying to use the Sun Studio Express compiler, from what I understand is the same as the Studio compiler with new features and performance updates ... to be included into the next Studio release. http://developers.sun.com/sunstudio/downloads/express/index.jsp?intcmp=2091cid=926973 Thanks, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Emulating libtool's -version-info with CMake?
2008/12/9 Shlomi Fish [EMAIL PROTECTED]: Hi all! I have a .so library (for Unix/Windows) that I maintain several versions of. I'd like to have a symbolic links structure similar to libtool's -version-info : http://www.ensta.fr/~diam/dev/online/autoconf/autobook/autobook_91.html The problem is that when doing ADD_LIBRARY, the resultant .so is just .so with no versions inside. How can I emulate the behaviour of libtool in this regard using CMake? SET_TARGET_PROPERTIES(yourlib PROPERTIES VERSION 1.0.0 SOVERSION 1) see http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:SOVERSION -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
Michael, Is there a way to call add_custom_command() on a specific configuration for a specific target? If I can do this then I can use CMAKE to copy the files appropriately and your method would work perfectly. Thanks for your tme. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Should changing, adding or removing add_definitions call trigger a recompile of affected files
I'm using CMake 2.6.3R5 on WinXP 64 using VS 2005 building a 32 bit binary. When I changed a CMake option it removed a call to add_definitions. The flags used to compile the project now changed. I thought I remember (and perhaps this was when I was using Makefiles more), that it should trigger a compile on the files that are now out of date. After configuring from cmake-gui, I clicked generate and the project reloaded. It started to compile, but everything was up to date. ??? Is this the intended behavior? I thought it used to cause recompiles of the affected files. Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] file(GLOB) for directories?
How would I use file( GLOB ) to get a list of directories instead of files? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking boost failure
Am Tuesday 09 December 2008 18:09:23 schrieb kafou nmento: Hi all! I'm compiling a Qt based libtorrent app with CMake using MinGW generator. For those not knowing libtorrent, it is a lib fully boost based. (boost version used 1.34.1). 100% of the build goes well. But at the linking it fails with errors like undefined reference to boost::. The most recurrent is boost::mutex related. I'm on Windows XP. The same app works fine with MSVC 2008. I used for both Visual and CMake the same libs and preprocessor definition. If some one can help me (^_^) Using mingw, you _must_ give the target_link_libraries() manually. Using msvc, autolinking is used but can be turned off. Have both active also works just fine. This is also described on the boost website. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] file(GLOB) for directories?
On Tue, Dec 9, 2008 at 12:30 PM, David Cole [EMAIL PROTECTED] wrote: file(GLOB with globbing expression of * and then iterate the results and ask if(IS_DIRECTORY on each result... Thanks, this works perfectly! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC71 WholeProgramOptimization flags (/LTCG and /GL)
Problem solved! I finally found some time today to checkout the CMake
source code and get setup for development. I started the build and found
the answer I was looking for in
cmLocalVisualStudio7Generator::OutputBuildTool() :
const char* tool = VCLibrarianTool;
fout \t\t\tTool\n
\t\t\t\tName=\ tool \\n;
if(const char* libflags =
target.GetProperty(STATIC_LIBRARY_FLAGS))
{
fout \t\t\t\tAdditionalOptions=\ libflags \\n;
}
Here is the solution that worked for me... if you have a similar problem
you can use the same concept for your situation:
If(WIN32 AND MSVC71)
String(REGEX MATCH /GL matchResult
${compilerFlagsDebug})
If(matchResult)
Set_Target_Properties(${targetFilenameDebug}
PROPERTIES
STATIC_LIBRARY_FLAGS /LTCG
)
EndIf()
String(REGEX MATCH /GL matchResult
${compilerFlagsRelease})
If(matchResult)
Set_Target_Properties(${targetFilenameRelease}
PROPERTIES
STATIC_LIBRARY_FLAGS /LTCG
)
EndIf()
EndIf()
Thanks again for everything. Our build system is now completely free of
errors and warnings!
Luke
From: Luke Kucalaba
Sent: Thursday, December 04, 2008 6:57 PM
To: cmake@cmake.org
Subject: MSVC71 WholeProgramOptimization flags (/LTCG and /GL)
Hi,
I would like to reopen issue #0006794 dealing with this linker warning
that is still present for MSVC 7.1 static library builds:
Linking CXX static library ..\build\MT-DLL\Util-SL.lib
XMLWriter.cpp.obj : warning LNK4218: non-native module found; restarting
I did some more investigation of this problem, and I think I've nailed
it down now. I thought it was the missing WholeProgramOptimization
element that was causing the warning, when in fact it is the missing
/LTCG flag that should be in the Librarian additional command-line
options. I realize that for a static library project the linker flags
are not included in the generated project file, but this should be an
exception case to that rule. As a general rule of thumb, if the /GL
compiler flag is passed to a static library project, then the /LTCG flag
should be passed to the Librarian AdditionalOptions line.
Tool
Name=VCLibrarianTool
AdditionalOptions=/LTCG
Thank you for your time and effort. I appreciate the hard work that you
have all done to make and keep CMake a high-quality software product.
Sincerely,
Luke
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tue, Dec 9, 2008 at 11:05 AM, Robert Dailey [EMAIL PROTECTED] wrote: Michael, Is there a way to call add_custom_command() on a specific configuration for a specific target? If I can do this then I can use CMAKE to copy the files appropriately and your method would work perfectly. Thanks for your tme. After much research, I've found out that CMake cannot provide a custom command (Post build event) to a specific configuration in the case where CMake is used to generate a multi-configuration target, such as a visual studio project. This is a HUGE problem for me. Are there any work-arounds for this issue? Does this issue plan to be addressed in a future release (Hopefully soon)? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tue, Dec 9, 2008 at 4:25 PM, Bill Hoffman [EMAIL PROTECTED]wrote: Robert Dailey wrote: After much research, I've found out that CMake cannot provide a custom command (Post build event) to a specific configuration in the case where CMake is used to generate a multi-configuration target, such as a visual studio project. This is a HUGE problem for me. Are there any work-arounds for this issue? Does this issue plan to be addressed in a future release (Hopefully soon)? Exactly what are you trying to copy? I might be able to figure out a workaround if I had a better idea of what you were doing. (please keep the example small... :) ) Sure. Sorry for the lack of details. I have a directory that contains DLL files that I need to copy to the directory at which my executable is built. However, the DLL files that I copy over are different depending on the configuration that was used to build the executable. For example, if I've built my executable using the DEBUG configuration, I need to copy over DLL files named foo_d.dll, bar_d.dll. If RELEASE was used to build the executable, then I need to copy over foo.dll and bar.dll. Since the debug/release executables are placed in different directories by CMake when they are built, the destination location for the DLLs also changes across configurations as well. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to add a libaray for another libaray?
Hello, My project is layout like this:
Linux-cmd$ tree
.
|-- CMakeLists.txt
|-- core
| |-- CMakeLists.txt
| |-- ... ... ...
| |-- (Some source files to implement the internal function.)
`-- ui
|-- CMakeLists.txt
|-- ... ... ...
|-- (Some source files to impliment the UI)
|-- main.cpp
Their dependences is main.cpp - ui - core
What's wrong with my CMakeLists.txt so that the files under the
directory ui can't
find the headers under the directory core.
1.ui/CMakeLists.txt :
# Make sure the compiler can find include files from our ui library.
INCLUDE_DIRECTORIES(${FREERECITE_SOURCE_DIR}/core)
# Make sure the linker can find the ui library once it is built.
LINK_DIRECTORIES(${FREERECITE_BINARY_DIR}/core)
TARGET_LINK_LIBRARIES(Cui.o core)
ADD_LIBRARY(ui Cui.cpp)
2. core/CMakeLists.txt:
# Set a variable $SRC_LIST to declare the source files.
SET(SRC_LIST ConfigHolder.cpp DictItem.cpp Reciter.cpp ForgetCurve.cpp
Task.cpp Dict.cpp Manager.cpp WordList.cpp)
# Create a library called Core which includes the source files.
# The extension is already found. Any number of sources could be listed
here.
ADD_LIBRARY(core ${SRC_LIST})
Thanks.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
On Tue, Dec 9, 2008 at 4:33 PM, Robert Dailey [EMAIL PROTECTED] wrote:
On Tue, Dec 9, 2008 at 4:25 PM, Bill Hoffman [EMAIL PROTECTED]wrote:
Robert Dailey wrote:
After much research, I've found out that CMake cannot provide a custom
command (Post build event) to a specific configuration in the case where
CMake is used to generate a multi-configuration target, such as a visual
studio project. This is a HUGE problem for me. Are there any work-arounds
for this issue? Does this issue plan to be addressed in a future release
(Hopefully soon)?
Exactly what are you trying to copy? I might be able to figure out a
workaround if I had a better idea of what you were doing.
(please keep the example small... :) )
Sure. Sorry for the lack of details.
I have a directory that contains DLL files that I need to copy to the
directory at which my executable is built. However, the DLL files that I
copy over are different depending on the configuration that was used to
build the executable. For example, if I've built my executable using the
DEBUG configuration, I need to copy over DLL files named foo_d.dll,
bar_d.dll. If RELEASE was used to build the executable, then I need to copy
over foo.dll and bar.dll. Since the debug/release executables are placed in
different directories by CMake when they are built, the destination location
for the DLLs also changes across configurations as well.
I actually did a little thinking and I came up with this:
add_custom_command( TARGET ${component_project_name}
POST_BUILD
COMMAND depends.py ARGS $(ConfigurationName)
)
Of course this only works for visual studio projects, but it does accomplish
what I want. The only downside is that I have to put the DLL copy logic in
the python script instead of keeping it centralized within CMake.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
2008/12/9 Robert Dailey [EMAIL PROTECTED]:
On Tue, Dec 9, 2008 at 11:05 AM, Robert Dailey [EMAIL PROTECTED] wrote:
Michael,
Is there a way to call add_custom_command() on a specific configuration
for a specific target? If I can do this then I can use CMAKE to copy the
files appropriately and your method would work perfectly.
Thanks for your tme.
After much research, I've found out that CMake cannot provide a custom
command (Post build event) to a specific configuration in the case where
CMake is used to generate a multi-configuration target, such as a visual
studio project. This is a HUGE problem for me. Are there any work-arounds
for this issue? Does this issue plan to be addressed in a future release
(Hopefully soon)?
I wonder if you could use the ctest --build-and-test tool, telling
it to configure (run cmake on) some custom little CMakeLists.txt-file
that could perform the copying. The ctest --build-and-test tool can
be given the --build-config-sample flag, that helps figuring out
whether it is a Debug or Release build currently going on. ctest can
thusly set the CMAKE_BUILD_TYPE variable when invoking cmake on that
custom CMakeLists.txt-file, so that the latter could perform the
copying based on that variable.
I'm not sure that I understand your problem correctly (and it's in the
middle of the night here) so I will not explain more now ... but take
a look at the following example and see if it is possible to
understand what it does .. (Note that it needs to be adapted for the
case where CMAKE_BUILD_TYPE is set as well in order to be generic, but
that is easy)
Best regards
Hugo Heden
Stockholm, Sweden
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
PROJECT(test)
# Create some dummy source (on the fly, but that is not necessary) and
#make sure it is compiled using a subdirectory with a CMakeLists.txt.
#The ctest --build-and-test (below) will later use the directory in which
#the executable ends up to figure out what build type this is. This is what
#the --build-config-sample flag is for.
FILE( WRITE
${CMAKE_CURRENT_BINARY_DIR}/dummy_src/CMakeLists.txt
ADD_EXECUTABLE( dummy dummy.cpp )
)
FILE( WRITE
${CMAKE_CURRENT_BINARY_DIR}/dummy_src/dummy.cpp
int main(){}
)
ADD_SUBDIRECTORY(
${CMAKE_CURRENT_BINARY_DIR}/dummy_src/
${CMAKE_CURRENT_BINARY_DIR}/dummy_build/
)
ADD_CUSTOM_TARGET( some_target
ALL
DEPENDS dummy
COMMAND
${CMAKE_CTEST_COMMAND}
--build-and-test ${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command
${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command
--build-generator ${CMAKE_GENERATOR}
--build-makeprogram ${CMAKE_BUILD_TOOL}
--build-noclean
--build-config-sample ${CMAKE_CURRENT_BINARY_DIR}/dummy_build/dummy
#--build-config ${CMAKE_BUILD_TYPE}
)
# Ok, finally, this is the CMakeLists.txt that will be invoked by the
#ctest-command above.. (here we create it on the fly, but that is
# not necessary)
FILE( WRITE
${CMAKE_CURRENT_BINARY_DIR}/tmp_custom_command/CMakeLists.txt
MESSAGE( STATUS \Woh - There is a build going on with
build type: \${CMAKE_BUILD_TYPE}\)
IF( \${CMAKE_BUILD_TYPE} STREQUAL \Debug\ )
MESSAGE( STATUS \Woh - here we could copy Debug-dll:s
to some Debug destination directory.\)
ELSEIF( \${CMAKE_BUILD_TYPE} STREQUAL \Release\ )
MESSAGE( STATUS \Woh - here we could copy
Release-dll:s to some Release destination directory.\)
ENDIF( \${CMAKE_BUILD_TYPE} STREQUAL \Debug\ )
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about install()
Robert Dailey wrote:
I actually did a little thinking and I came up with this:
add_custom_command( TARGET ${component_project_name}
POST_BUILD
COMMAND depends.py ARGS $(ConfigurationName)
)
Of course this only works for visual studio projects, but it does
accomplish what I want. The only downside is that I have to put the DLL
copy logic in the python script instead of keeping it centralized within
CMake.
You do know about CMAKE_CFG_INTDIR right? It will expand out to the
configuration directory name on VS and Xcode, and for makefiles it will
be ..
So, you could have:COMMAND depends.py ARGS ${CMAKE_CFG_INTDIR}. It
will not help with the separate named targets, but it will give you the
directory that they are in. If you did not want to use python, you
could use cmake -DCONFIG=${CMAKE_CFG_INTDIR} -E myscript.cmake.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Should changing, adding or removing add_definitions call trigger a recompile of affected files
On Tue, Dec 9, 2008 at 1:08 PM, Philip Lowman [EMAIL PROTECTED] wrote: This is a known problem. Visual Studio has no way of knowing that the compiler flags changed in a project file CMake is writing to. I would love to see a patch for this for CMake 2.8. One thought I had here was to have the vcbuild command clean any affected projects. This would have the advantage of isolating CMake from implementing any Visual Studio specific mods (i.e. delete these object files to force a recompilation, etc.). This would have some downsides though. 1. The easiest implementation would just be to perform the clean if a project file changes. This would result in more cleaning then necessary as changing source files (for example) shouldn't cause a rebuild. Certain project modifications like adding a source file to a target shouldn't cause a clean of that target. 2. Perhaps the biggest gotcha of all, cleaning a target would wipe out any binaries/libraries already generated. This is far different from the behavior of CMake's Makefile generator which simply causes targets to be rebuilt on the next make. Anyone have any ideas for fixing this? I've been bit by this one before (forgetting to rebuild everything when I change a preprocessor definition at the global scope). -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] [PATCH] Support for = and = operators in IF() conditional
Sent this in a few days ago for any who are interested. http://public.kitware.com/Bug/view.php?id=8222 It's not bloat, it's convenience! =) -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Linking object files into executable target
I'm using CMake and SDCC to build a project for the 8051
microcontroller. CMake has been working great for this so far, but now
I need to link in an object file that I've assembled with SDCC's
asx8051 assembler, and I am not able to get CMake to explicitly add
an object file to the list of objects to be linked into a target.
The problem is that CMake is *silently* ignoring the request to link the
object file into the executable target with ADD_EXECUTABLE().
First, I am using ADD_CUSTOM_COMMAND to assemble the assembly code into
an object file (.rel extension, as are the object files produced by
SDCC for compiled C code). The custom command is resulting in the
object file being produced properly.
Next, my ADD_EXECUTABLE() call simply names the object file in addition
to the C source files that I already am specifying. However, while the
C source files are compiled and linked with into the target executable,
the '.rel' object file is not being added into the list of objects to
link into the executable.
I think that the GENERATED=TRUE and EXTERNAL_OBJECT=TRUE source
properties on the generated object file should cause CMake to link it.
Is there something I'm doing wrong?
Here's my CMakeLists.txt:
-
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
PROJECT(timertest C)
SET(CMAKE_ASM_OUTPUT_EXTENSION ${CMAKE_C_OUTPUT_EXTENSION})
SET(MY_SRCS main.c)
SET(MY_ASM_SRCS sleep_timer_get.asm)
FOREACH(ASMFILE ${MY_ASM_SRCS})
GET_FILENAME_COMPONENT(BASENAME ${ASMFILE} NAME_WE)
SET(SRC ${CMAKE_CURRENT_SOURCE_DIR}/${ASMFILE})
SET(OBJ
${CMAKE_CURRENT_BINARY_DIR}/${BASENAME}${CMAKE_ASM_OUTPUT_EXTENSION})
SET_SOURCE_FILES_PROPERTIES(${OBJ} PROPERTIES
GENERATED TRUE
EXTERNAL_OBJECT TRUE)
ADD_CUSTOM_COMMAND(OUTPUT ${OBJ}
MAIN_DEPENDENCY ${SRC}
COMMAND asx8051-wrapper
ARGS -I${CMAKE_CURRENT_SOURCE_DIR}
-o ${OBJ} ${SRC})
LIST(APPEND MY_ASM_OBJS ${OBJ})
ENDFOREACH(ASMFILE ${MY_ASM_SRCS})
MESSAGE(STATUS MY_ASM_OBJS is ${MY_ASM_OBJS})
ADD_EXECUTABLE(timertest main.c ${MY_ASM_OBJS})
-
I have attached the output I get when I build using this file.
I have spent all day and most of the night trying to get this to work,
and I've already started working on a Makefile to replace CMake for
this, though I really would hate to give up CMake; however, this silent
failure by CMake is creating an impossible-to-track-down problem.
Thanks for any help.
Regards,
Colin[EMAIL PROTECTED] ~/vdsi/beacon-work/tmp-test/out9 $ cmake-sdcc ..
-- The C compiler identification is SDCC
-- Check for working C compiler: /home/cdb/bin/sdcc/bin/sdcc
-- Check for working C compiler: /home/cdb/bin/sdcc/bin/sdcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- MY_ASM_OBJS is /home/cdb/vdsi/beacon-work/tmp-test/out9/sleep_timer_get.rel
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cdb/vdsi/beacon-work/tmp-test/out9
[EMAIL PROTECTED] ~/vdsi/beacon-work/tmp-test/out9 $ make VERBOSE=1
/usr/bin/cmake -H/home/cdb/vdsi/beacon-work/tmp-test
-B/home/cdb/vdsi/beacon-work/tmp-test/out9 --check-build-system
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/cdb/vdsi/beacon-work/tmp-test/out9/CMakeFiles
/home/cdb/vdsi/beacon-work/tmp-test/out9/CMakeFiles/progress.make
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/cdb/vdsi/beacon-work/tmp-test/out9'
make -f CMakeFiles/timertest.dir/build.make CMakeFiles/timertest.dir/depend
make[2]: Entering directory `/home/cdb/vdsi/beacon-work/tmp-test/out9'
/usr/bin/cmake -E cmake_progress_report
/home/cdb/vdsi/beacon-work/tmp-test/out9/CMakeFiles 2
[ 50%] Generating sleep_timer_get.rel
asx8051-wrapper -I/home/cdb/vdsi/beacon-work/tmp-test -o
/home/cdb/vdsi/beacon-work/tmp-test/out9/sleep_timer_get.rel
/home/cdb/vdsi/beacon-work/tmp-test/sleep_timer_get.asm
SRC: '/home/cdb/vdsi/beacon-work/tmp-test/sleep_timer_get.asm'
OBJ: '/home/cdb/vdsi/beacon-work/tmp-test/out9/sleep_timer_get.rel'
Running assembler...
`/home/cdb/vdsi/beacon-work/tmp-test/sleep_timer_get.rel' -
`/home/cdb/vdsi/beacon-work/tmp-test/out9/sleep_timer_get.rel'
`/home/cdb/vdsi/beacon-work/tmp-test/sleep_timer_get.lst' -
`/home/cdb/vdsi/beacon-work/tmp-test/out9/sleep_timer_get.lst'
`/home/cdb/vdsi/beacon-work/tmp-test/sleep_timer_get.sym' -
`/home/cdb/vdsi/beacon-work/tmp-test/out9/sleep_timer_get.sym'
cd /home/cdb/vdsi/beacon-work/tmp-test/out9 /usr/bin/cmake -E cmake_depends
Unix Makefiles /home/cdb/vdsi/beacon-work/tmp-test
/home/cdb/vdsi/beacon-work/tmp-test /home/cdb/vdsi/beacon-work/tmp-test/out9
/home/cdb/vdsi/beacon-work/tmp-test/out9
/home/cdb/vdsi/beacon-work/tmp-test/out9/CMakeFiles/timertest.dir/DependInfo.cmake
--color=
Dependee
