Re: [CMake] Bug fix requests for the *next* release of CMake...
Hi David, http://public.kitware.com/Bug/view.php?id=11896 Thanks, Shash -Original Message- From: cmake-boun...@cmake.org on behalf of David Cole Sent: Tue 3/29/2011 12:56 PM To: cmake; CMake Developers Subject: [CMake] Bug fix requests for the *next* release of CMake... Hi all, Now that we have released CMake 2.8.4, *now* would be a great time to prioritize bug fixes for the next release of CMake. Replies requested. Read on. *Just a short reply with bug numbers* or links to the bugs is all we need here. ___ 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] Eclipse generator - scanner-discovered include pathsand pre-processor symbols
Hi Alex,
Thanks for the change. The version you sent didn't end up working here (with
just a CXX project). The line to set the compiler is checking for CXX but,
at least on my system, ${_lang} is set to c++. Once I changed the line to
check for CXX or c++, it worked fine. I also noticed that /usr/include was
not being added, and it was because the regexp was skipping the last line of
includes. I have modified the regexp slightly, and that worked as well. I
have attached the changed file for you to compare, I am not sure if the changes
are just specific to my system.
Thanks,
Shash
-Original Message-
From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net]
Sent: Sun 3/27/2011 11:24 AM
To: cmake@cmake.org
Cc: Chatterjee, Shash
Subject: Re: [CMake] Eclipse generator - scanner-discovered include pathsand
pre-processor symbols
Ah, indeed, it was using CMAKE_C_COMPILER also when finding out the C++ stuff,
which works, but only if CMAKE_C_COMPILER is actually set.
Please try the attached version, this should also work with your CXX-only
project.
Let me know whether it works for you.
Thanks
Alex
#=
# Copyright 2009 Kitware, Inc.
#
# Distributed under the OSI-approved BSD License (the License);
# see accompanying file Copyright.txt for details.
#
# This software is distributed WITHOUT ANY WARRANTY; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the License for more information.
#=
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
# This file is included in CMakeSystemSpecificInformation.cmake if
# the Eclipse CDT4 extra generator has been selected.
FIND_PROGRAM(CMAKE_ECLIPSE_EXECUTABLE NAMES eclipse DOC The Eclipse executable)
# This variable is used by the Eclipse generator and appended to the make invocation commands.
SET(CMAKE_ECLIPSE_MAKE_ARGUMENTS CACHE STRING Additional command line arguments when Eclipse invokes make. Enter e.g. -jsome_number to get parallel builds)
# This variable is used by the Eclipse generator in out-of-source builds only.
SET(ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT FALSE CACHE BOOL If enabled, CMake will generate a source project for Eclipse in CMAKE_SOURCE_DIR)
MARK_AS_ADVANCED(ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT)
# The Eclipse generator needs to know the standard include path
# so that Eclipse ca find the headers at runtime and parsing etc. works better
# This is done here by actually running gcc with the options so it prints its
# system include directories, which are parsed then and stored in the cache.
MACRO(_DETERMINE_GCC_SYSTEM_INCLUDE_DIRS _lang _resultIncludeDirs _resultDefines)
message(STATUS Getting include dirs for ${_lang} ...)
SET(${_resultIncludeDirs})
SET(_gccOutput)
FILE(WRITE ${CMAKE_BINARY_DIR}/CMakeFiles/dummy \n )
IF (${_lang} STREQUAL CXX OR ${_lang} STREQUAL c++)
SET(_compilerExecutable ${CMAKE_CXX_COMPILER})
ELSE (${_lang} STREQUAL CXX OR ${_lang} STREQUAL c++)
SET(_compilerExecutable ${CMAKE_C_COMPILER})
ENDIF (${_lang} STREQUAL CXX OR ${_lang} STREQUAL c++)
EXECUTE_PROCESS(COMMAND ${_compilerExecutable} -v -E -P -x ${_lang} -dD dummy
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/CMakeFiles
ERROR_VARIABLE _gccOutput
OUTPUT_VARIABLE _gccStdout )
FILE(REMOVE ${CMAKE_BINARY_DIR}/CMakeFiles/dummy)
MESSAGE(STATUS stderr: -${_gccOutput}-)
MESSAGE(STATUS stdout: -${_gccStdout}-)
# First find the system include dirs:
IF( ${_gccOutput} MATCHES search starts here[^\n]+\n *(.+ *\n) *End of (search) list )
# split the output into lines and then remove leading and trailing spaces from each of them:
STRING(REGEX MATCHALL [^\n]+\n _includeLines ${CMAKE_MATCH_1})
FOREACH(nextLine ${_includeLines})
STRING(STRIP ${nextLine} _includePath)
LIST(APPEND ${_resultIncludeDirs} ${_includePath})
ENDFOREACH(nextLine)
ENDIF( ${_gccOutput} MATCHES search starts here[^\n]+\n *(.+ *\n) *End of (search) list )
# now find the builtin macros:
STRING(REGEX MATCHALL #define[^\n]+\n _defineLines ${_gccStdout})
# A few example lines which the regexp below has to match properly:
# #define MAX(a,b) ((a) (b) ? (a) : (b))
# #define __fastcall __attribute__((__fastcall__))
# #define FOO (23)
# #define __UINTMAX_TYPE__ long long unsigned int
# #define __UINTMAX_TYPE__ long long unsigned int
# #define __i386__ 1
FOREACH(nextLine ${_defineLines})
STRING(REGEX MATCH ^#define +([A-Za-z_][A-Za-z0-9_]*)(\\([^\\)]+\\))? +(.+) *$ _dummy ${nextLine})
SET(_name ${CMAKE_MATCH_1}${CMAKE_MATCH_2})
STRING(STRIP ${CMAKE_MATCH_3} _value)
#MESSAGE(STATUS m1: -${CMAKE_MATCH_1}- m2: -${CMAKE_MATCH_2}- m3: -${CMAKE_MATCH_3}-)
LIST(APPEND ${_resultDefines} ${_name
Re: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols
Hi Alex, - CMakeFindEclipseCDT4.cmake : this is slightly changed version from the one shipped with cmake 2.8.4, it produces debug output. Please replace the CMakeFindEclipseCDT4.cmake in your cmake 2.8.4 installation with this file. Then create a fresh and empty build directory, and let cmake run there, with the same command line as you posted. Capture the output, both stdout and stderr in a log file and post it here. Thanks for sending this, most illuminating :-) I saw that you are using ccache, maybe this behaves slightly different for some things ? I am using Fedora Core 14, with all latest yum updates. I have not done anything knowingly for cmake to prefer ccache over gcc directly, so looks like by default cmake will use ccache over straight GCC if it finds it. Of course, the speedup is most welcome. I have attached two versions of the log output. The first one is with the problem reproduced. I noticed in your debug output that the C compiler was being detected as blank, and no C++ include directories were being found even though the compiler was detected as GNU. I changed the project definition in my CMakeLists.txt from project ( eclipsetest CXX ) to project ( eclipstest C CXX ) and everything worked as expected. Thanks, Shash -- The CXX compiler identification is GNU -- This is CMakeFindEclipse.cmake, compiler id is -- , -GNU- -- Getting include dirs for c++ ... -- stderr: -- -- stdout: -- -- Check for working CXX compiler: /usr/lib/ccache/c++ -- Check for working CXX compiler: /usr/lib/ccache/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/schatterjee/views/eclipsetest/build/eclipse-debug -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- This is CMakeFindEclipse.cmake, compiler id is -GNU- , -GNU- -- Getting include dirs for c ... -- stderr: -Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.5.1/lto-wrapper Target: i686-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux Thread model: posix gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) COLLECT_GCC_OPTIONS='-v' '-E' '-dD' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-redhat-linux/4.5.1/cc1 -E -quiet -v dummy -mtune=generic -march=i686 -dD ignoring nonexistent directory /usr/lib/gcc/i686-redhat-linux/4.5.1/include-fixed ignoring nonexistent directory /usr/lib/gcc/i686-redhat-linux/4.5.1/../../../../i686-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i686-redhat-linux/4.5.1/include /usr/include End of search list. COMPILER_PATH=/usr/libexec/gcc/i686-redhat-linux/4.5.1/:/usr/libexec/gcc/i686-redhat-linux/4.5.1/:/usr/libexec/gcc/i686-redhat-linux/:/usr/lib/gcc/i686-redhat-linux/4.5.1/:/usr/lib/gcc/i686-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/i686-redhat-linux/4.5.1/:/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-E' '-dD' '-mtune=generic' '-march=i686' - -- stdout: -# 1 dummy # 1 built-in #define __STDC__ 1 #define __STDC_HOSTED__ 1 #define __GNUC__ 4 #define __GNUC_MINOR__ 5 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC_RH_RELEASE__ 4 #define __SIZE_TYPE__ unsigned int #define __PTRDIFF_TYPE__ int #define __WCHAR_TYPE__ long int #define __WINT_TYPE__ unsigned int #define __INTMAX_TYPE__ long long int #define __UINTMAX_TYPE__ long long unsigned int #define __CHAR16_TYPE__ short unsigned int #define __CHAR32_TYPE__ unsigned int #define __SIG_ATOMIC_TYPE__ int #define __INT8_TYPE__ signed char #define __INT16_TYPE__ short int #define __INT32_TYPE__ int #define __INT64_TYPE__ long long int #define __UINT8_TYPE__ unsigned char #define __UINT16_TYPE__ short unsigned int #define __UINT32_TYPE__ unsigned int #define __UINT64_TYPE__ long long unsigned int #define __INT_LEAST8_TYPE__ signed char #define __INT_LEAST16_TYPE__ short int #define __INT_LEAST32_TYPE__ int #define __INT_LEAST64_TYPE__ long long int #define __UINT_LEAST8_TYPE__ unsigned char #define __UINT_LEAST16_TYPE__ short unsigned int #define __UINT_LEAST32_TYPE__ unsigned int #define __UINT_LEAST64_TYPE__ long long unsigned int #define
Re: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols
BTW, the command I used for cmake was: cd build/eclipsetest cmake -GEclipse CDT4 - Unix Makefiles -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE -DCMAKE_BUILD_TYPE=Debug ../../eclipsetest -Original Message- From: Chatterjee, Shash Sent: Thu 3/24/2011 8:47 AM To: a.neundorf-w...@gmx.net Cc: cmake@cmake.org Subject: RE: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols Hi Alex, I have attached a tar file with a tiny example project that shows the behaviour. Screenshot-1 shows the problem (this is the config included in the tar file), Screenshot-2 shows the state after I fixed it manually. Thanks, Shash -Original Message- From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] Sent: Sun 3/20/2011 11:33 AM To: Chatterjee, Shash Cc: cmake@cmake.org Subject: Re: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols On Wednesday 16 March 2011, Chatterjee, Shash wrote: Hi Alex, In my case, I get little yellow icons with a question mark on the editor's left-hand gutter, with a unresolved inclusion: blah. This happens on every new import, but also if I make changes to any CMakeLists.txt file within the project and CMake regenerates the .cproject file. On my project, without the path container, I do not have (see attached screenshot) paths like: /usr/include/c++/4.5.1 /usr/include/c++/4.5.1/i686-redhat-linux /usr/include/c++/4.5.1/backward /usr/local/include /usr/lib/gcc/i686-redhat-linux/4.5.1/include /usr/include I do not have these paths included explicitly with INCLUDE_DIRECTORIES() (and I do just that to temporarily workaround this). I suspect that in your project these paths are explicitly defined somewhere, or, No, I don't. I just tried again, and I don't get the little yellow icons for stuff like stdio.h. Adding the line you propose doesn't change the behaviour here. Can you send me such a .cproject file from your system where it doesn't work ? Maybe for some reason the collecting of built-in include dirs and macros doesn't work on your system. 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] Eclipse generator - scanner-discovered include pathsand pre-processor symbols
I am using 2.8.4 (on Fedora Core 13). -Original Message- From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] Sent: Wed 3/16/2011 12:04 PM To: Chatterjee, Shash Cc: cmake@cmake.org Subject: Re: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols On Wednesday 16 March 2011, Chatterjee, Shash wrote: Hi Alex, In my case, I get little yellow icons with a question mark on the editor's left-hand gutter, with a unresolved inclusion: blah. This happens on every new import, but also if I make changes to any CMakeLists.txt file within the project and CMake regenerates the .cproject file. which version of cmake are you actually using ? 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] Eclipse generator - scanner-discovered include pathsand pre-processor symbols
Hi Alex, Yes, that is correct, that one pathentry line added to .cproject is all that is needed from the generator. The scanner simply detects the built-in symbols and paths and sticks them in the container. Then, the container contribution has to be added as part of the project paths. Then, the indexer can find all the include files, and the pre-processor conditions work correctly. Or, at least, that is my understanding :-). Thanks, Shash -Original Message- From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] But all you want is to add the line pathentry kind=con path=org.eclipse.cdt.make.core.DISCOVERED_SCANNER_INFO/ to the file ? And even with all the builtin include dirs and macros already in the .cproject file, the indexer still needs to find them again itself ? ___ 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] Eclipse generator - scanner-discovered include pathsand pre-processor symbols
Hi Alex, The included dirs and preprocessor symbols that are added, come from the CMake definitions, and are needed. The container defintion is different, it adds the dirs and symbols that are built-in to the compiler/pre-processor, and the scanner detects those within Eclipse/CDT. So, yes the container definition needs to be added, but it is not really twice. Shash -Original Message- From: cmake-boun...@cmake.org on behalf of Alexander Neundorf Sent: Sat 3/12/2011 2:12 PM To: David Cole Cc: cmake@cmake.org Subject: Re: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols So that stuff (included dirs and preprocessor symbols) has to be put twice into the project files ? ___ 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 generator - scanner-discovered include paths and pre-processor symbols
Hi, Using CDT-2.8.2 on Fedora Core 14, and Eclipse Indigo/CDT (20101216-1529). Most everything works fine in the .project/.cproject, except the CDT indexer cannot find the compiler's built-in include paths/files and pre-processor symbols. To fix that, all that has to be done is to go into the project Properties-C/C++ Project Paths-Path Containers-Add-Discovered scanner configuration container. All that does is add the following under the storageModule moduleId=org.eclipse.cdt.core.pathentry element in .cproject: pathentry kind=con path=org.eclipse.cdt.make.core.DISCOVERED_SCANNER_INFO/ Can this be added to the Eclipse generator? Thanks, Shash ___ 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] Including an external object file (.o) into static shared library using MS Visual Studio generator
Hi David, I created a bug report (http://public.kitware.com/Bug/view.php?id=11896). It has an attached tar-file with a sample project that reproduces the problem. Thanks, Shash --- The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the sender immediately. Please do not disclose the contents to anyone else. Please do not make copies of the contents or any attachments. Thank you for your cooperation. --- -Original Message- From: David Cole [mailto:david.c...@kitware.com] Sent: Thursday, February 17, 2011 3:40 PM To: Chatterjee, Shash Subject: Re: [CMake] Including an external object file (.o) into static shared library using MS Visual Studio generator Create a bug report if you can attach an example project that demonstrates the issue. On Thu, Feb 17, 2011 at 4:32 PM, Chatterjee, Shash schatter...@camber.com wrote: Hi David, There are way too many build files to add it to each executable, even inside our system. To make matters worse, all our customer builds would break as well, not an option! In a prior email, I sent you a rss.vcxproj file that works. If you search for kfunc.obj, you will see what makes it work. I do understand your time pressure, and can live with manually adding it to the VS project until it is fixed. Should I create a bug report for this? Thanks again for your help, Shash -Original Message- From: David Cole [mailto:david.c...@kitware.com] Sent: Thursday, February 17, 2011 3:25 PM To: Chatterjee, Shash Subject: Re: [CMake] Including an external object file (.o) into static shared library using MS Visual Studio generator Actually, I don't know if you can include a *.obj in a *static* library this way. I'd have to experiment and/or do some research. I don't have time for either in the next few days, though... Why can't you add it to the executables that need it? On Thu, Feb 17, 2011 at 4:22 PM, David Cole david.c...@kitware.com wrote: And what is the build error that you're seeing? On Thu, Feb 17, 2011 at 4:21 PM, Chatterjee, Shash schatter...@camber.com wrote: Yes, I tried the .obj with 2.8.4, and it made the difference from ClInclude to None, but that's it. --- The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the sender immediately. Please do not disclose the contents to anyone else. Please do not make copies of the contents or any attachments. Thank you for your cooperation. --- -Original Message- From: David Cole [mailto:david.c...@kitware.com] Sent: Thursday, February 17, 2011 3:18 PM To: Chatterjee, Shash Subject: Re: [CMake] Including an external object file (.o) into static shared library using MS Visual Studio generator Did you try using kfunc.obj instead of kfunc.o with CMake 2.8.4? On Thu, Feb 17, 2011 at 3:31 PM, Chatterjee, Shash schatter...@camber.com wrote: The difference in the vcxproj file is that instead of the ClInclude element, it creates a new ItemGroup and sticks a None element with the .obj. In VS10, previously kfunc.o (with ClInclude) had an icon for an unknown type, now it has a specific icon. However, it still does not add to the library. I have attached the CMake-generated vcxproj: rss-does-not-work.vcxproj I have attached the vcxproj after I manually added: rss.vcxproj -Original Message- From: David Cole [mailto:david.c...@kitware.com] Sent: Thursday, February 17, 2011 1:41 PM To: Chatterjee, Shash Subject: Re: [CMake] Including an external object file (.o) into static shared library using MS Visual Studio generator If you copy it to a file name ending with .obj does it work? 2011/2/17 Chatterjee, Shash schatter...@camber.com: Hi David, Just sending to you directly since it might not be a good idea to post this publicly. Hopefully, this is OK with you. Thanks, Shash --- The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the sender immediately. Please do not disclose the contents to anyone else. Please do not make copies of the contents or any attachments. Thank you for your cooperation. --- -Original Message- From: David Cole [mailto:david.c...@kitware.com] Sent: Thursday, February 17, 2011 1:23 PM To: Chatterjee, Shash Cc: cmake@cmake.org Subject: Re: [CMake] Including an external object file (.o) into static shared library using MS Visual Studio generator Can you send your CMakeLists.txt file? Or at least copy/paste the relevant portion of it so we can see how you're adding the file? Actually, maybe you won't need to send us code... It needs to be a *.obj file to work with the Visual Studio generators
[CMake] Including an external object file (.o) into static shared library using MS Visual Studio generator
Hi! I need to include a 3rd-party API, which comes without source, as an object (.o) file into a static library using CMake 2.8.3. I know it is possible to add the .o when executables are linked, but that is not the preferred method. I have simply defined the .o file in the ADD_LIBRARY command. This works under linux, and nmake (MS Visual Studio 10 /2010). If I look in the cmake-generated build.make, CMake correctly recognizes the .o as an external dependency and defines a libname_EXTERNAL_OBJECTS variable in there, and it is listed at the tail end of objects1.rsp. So far, so good! When using the Visual Studio 10 generator, CMake adds the object file as a ClInclude Include=./ XML element under a ItemGroup element that also lists all the source files as ClCompile elements for the static library project. Of course the .o is not include in the lib when the project is built. I can manually go into the project properties, and add it as an Additional Dependencies dependency for the Librarian, and that works. Is there a way to get CMake to do this automatically? Thanks, Shash ___ 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] Including an external object file (.o) into static shared library using MS Visual Studio generator
Hi David, I truly appreciate your willingness to help, and your prompt response. Thanks a bunch! I just installed 2.8.4 and tried again. As far as I can tell, the behavior did not change (I deleted the CMake-2.8.3 generated build directory, as well as uninstalling CMake-2.8.3). I still see the ClInstall element for the .o file, and it does not get included in the library. Thanks, Shash -Original Message- From: David Cole [mailto:david.c...@kitware.com] Sent: Thursday, February 17, 2011 12:23 PM To: Chatterjee, Shash Cc: cmake@cmake.org Subject: Re: [CMake] Including an external object file (.o) into static shared library using MS Visual Studio generator This was a known bug, and has been fixed in CMake 2.8.4. See here for details if you want: http://public.kitware.com/Bug/view.php?id=11459 Upgrade to CMake 2.8.4 and try again. Should work Cheers, David On Thu, Feb 17, 2011 at 12:59 PM, Chatterjee, Shash schatter...@camber.com wrote: Hi! I need to include a 3rd-party API, which comes without source, as an object (.o) file into a static library using CMake 2.8.3. I know it is possible to add the .o when executables are linked, but that is not the preferred method. I have simply defined the .o file in the ADD_LIBRARY command. This works under linux, and nmake (MS Visual Studio 10 /2010). If I look in the cmake-generated build.make, CMake correctly recognizes the .o as an external dependency and defines a libname_EXTERNAL_OBJECTS variable in there, and it is listed at the tail end of objects1.rsp. So far, so good! When using the Visual Studio 10 generator, CMake adds the object file as a ClInclude Include=./ XML element under a ItemGroup element that also lists all the source files as ClCompile elements for the static library project. Of course the .o is not include in the lib when the project is built. I can manually go into the project properties, and add it as an Additional Dependencies dependency for the Librarian, and that works. Is there a way to get CMake to do this automatically? Thanks, Shash ___ 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
