[cmake-developers] [CMake 0011896]: ".obj" or ".o" listed in ADD_LIBRARY does not get included in Visual Studio project, NMake build works
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11896 == Reported By:Shash Chatterjee Assigned To: == Project:CMake Issue ID: 11896 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-02-24 15:26 EST Last Modified: 2011-02-24 15:26 EST == Summary:".obj" or ".o" listed in ADD_LIBRARY does not get included in Visual Studio project, NMake build works Description: When adding an object-file (pre-compiled, available only in binary form from 3rd-party) to a library, the object file does not get included in the library when built under Visual Studio (tried Visual Studio 10/2010 and 8/2005). When using NMake, for both VS-10 and VS-8, the object is included correctly. If the project file for the library is updated manually, by selecting the project properties, and then adding the .o/.obj as an "Additional Dependencies" for the Librarian properties, then the build works. Steps to Reproduce: An example source tree and 2 build directories are attached. == Issue History Date ModifiedUsername FieldChange == 2011-02-24 15:26 Shash ChatterjeeNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] How to deal with assembler files
On Wednesday 23 February 2011, Brad King wrote:
> On 02/23/2011 03:36 PM, Alexander Neundorf wrote:
> > This is now on stage in the "ReworkedAsmSupport" branch.
> > I'd like to merge this into next, if there are no objections.
> > It implements what we discussed here, i.e. if there is already a C/CXX
> > compiler it tries to use that too for assembler, if not, it tries to find
> > such a compiler.
>
> Looks good! BTW, this block:
>
> +if(CMAKE_C_COMPILER_ID STREQUAL "GNU"
> + OR CMAKE_C_COMPILER_ID STREQUAL "HP"
> + OR CMAKE_C_COMPILER_ID STREQUAL "Intel"
> + OR CMAKE_C_COMPILER_ID STREQUAL "SunPro"
> + OR CMAKE_C_COMPILER_ID STREQUAL "XL")
> ...
> +endif(CMAKE_C_COMPILER_ID STREQUAL "GNU"
> + OR CMAKE_C_COMPILER_ID STREQUAL "HP"
> + OR CMAKE_C_COMPILER_ID STREQUAL "Intel"
> + OR CMAKE_C_COMPILER_ID STREQUAL "SunPro"
> + OR CMAKE_C_COMPILER_ID STREQUAL "XL")
>
> is more easily written
>
> if("${CMAKE_C_COMPILER_ID}" MATCHES "^(GNU|HP|Intel|SunPro|XL)$")
> ...
> endif()
Ok.
I merged this now into next on stage.
I also removed the "Assembler support is still experimental" message now.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Test failing because Test directory is not clean
2011/2/23 Eric Noulard : > 2011/2/23 Clinton Stimpson : > >> I've having problems with these tests too. >> If they fail once, they will keep failing until some files generated by the >> failed test are cleaned up. > > Some files should be, the package files located at the root of the build dir. > >> Seems to me that an extra cleanup step should be done before or during the >> "ctest --build-and-test " for these tests that glob for generated files. >> Could you do this with a ctest script that cleans the test specific build >> directory before doing the configure/build/test? And call that ctest script >> in the add_test() call? >> I'm not sure if this is a good idea, but what if the glob was done under the >> _CPack_Packages directory which cpack always cleans beforehand. > > In my case it wouldn't be enough to kill _CPack_Packages there will remain > spurious files in the build tree. I did pushed forward the CPack-ChangeComponentNamingScheme branch the test itself is cleaning up the build tree from expected package files before running CPack. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011891]: Visual Studio 2010 Generator adds .obj as "not part of this build" to projects
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=11891 == Reported By:jfbos2 Assigned To: == Project:CMake Issue ID: 11891 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-02-24 03:21 EST Last Modified: 2011-02-24 03:21 EST == Summary:Visual Studio 2010 Generator adds .obj as "not part of this build" to projects Description: When you add .obj files that already exist and want to add them to the executable or library sources, the Visual Studio 2010 Generator add the file to the Project but it is marked as "not part of this build" and not linked with the executable or library. If you look in the .vxproj file is says..: ... ... Instead it should read: Steps to Reproduce: 1) Use the following CMakeLists.txt: cmake_minimum_required(VERSION 2.6) project(testProj CXX) add_executable(test main.cpp stack.obj) # the following doesn't seem to affect anything, at least with VS2010 Generator set_source_files_properties( stack.obj PROPERTIES EXTERNAL_OBJECT TRUE ) - with simple main.cpp and any .obj file, 2) run cmake with Visual Studio 2010 Generator 3) Open solution -> stack.obj is added as "Not part of this build" and the object file is not linked with the executable or library == Issue History Date ModifiedUsername FieldChange == 2011-02-24 03:21 jfbos2 New Issue 2011-02-24 03:21 jfbos2 File Added: CMakeLists.txt == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
