View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0009568CMakeCMakepublic2009-09-19 00:572009-10-01 10:30
ReporterShirokov Anatoly 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0009568: Visual Studio 6 generator issue
DescriptionVisual Studio 6 generator does not include all dependencies into workspaces for nested project.
Additional InformationI have a simple project with the following structure:
root
  CMakeLists.txt
  app
     CMakeLists.txt
     app.cpp
  lib
     CMakeLists.txt
     lib.cpp

The root\CMakeLists.txt contains:
cmake_minimum_required(VERSION 2.6)
project(ROOT)
add_subdirectory(app)
add_subdirectory(lib)

The root\app\CMakeLists.txt contains:
project( APP )
add_executable( app app.cpp )
target_link_libraries( app lib )
add_dependencies( app lib )

The root\app\CMakeLists.txt contains:
project( LIB )
add_library( lib STATIC lib.cpp)

I try to generate Visual Studio 6 project:
cd root
mkdir build
cd build
cmake -G "Visual Studio 6" ..

CMake generates the following:
ALL_BUILD.dsp
ALL_BUILD.dsp.cmake
CMakeCache.txt
cmake_install.cmake
ROOT.dsw
app\ALL_BUILD.dsp
app\ALL_BUILD.dsp.cmake
app\app.dsp
app\app.dsp.cmake
app\APP.dsw
app\CMakeFiles
app\cmake_install.cmake
app\CMakeFiles\ALL_BUILD.rule
CMakeFiles\ALL_BUILD.rule
CMakeFiles\cmake.check_cache
CMakeFiles\CMakeCCompiler.cmake
CMakeFiles\CMakeCPlatform.cmake
CMakeFiles\CMakeCXXCompiler.cmake
CMakeFiles\CMakeCXXPlatform.cmake
CMakeFiles\CMakeDetermineCompilerABI_C.bin
CMakeFiles\CMakeDetermineCompilerABI_CXX.bin
CMakeFiles\CMakeOutput.log
CMakeFiles\CMakeRCCompiler.cmake
CMakeFiles\CMakeSystem.cmake
CMakeFiles\CMakeTmp
CMakeFiles\CMakeTmp\CMakeFiles
CMakeFiles\CMakeTmp\Debug
lib\ALL_BUILD.dsp
lib\ALL_BUILD.dsp.cmake
lib\CMakeFiles
lib\cmake_install.cmake
lib\lib.dsp
lib\lib.dsp.cmake
lib\LIB.dsw
lib\CMakeFiles\ALL_BUILD.rule

When I open ROOT.dsw, I can build all targets correctly according to dependencies. Why cannot I do the same when I open nested app\APP.dsw workspace?
In other words, why does not CMake include the lib project into the APP.DSW workspace?

I have tested the Visual Studio 2005 generator for this project. There are no such problems with one. The app.sln solution includes lib.vcproj as expected.

It looks like something is wrong with Visual Studio 6 generator.
TagsNo tags attached.
Attached Filestxt file icon cmGlobalVisualStudio6Generator.cxx.patch.txt [^] (17,590 bytes) 2009-09-19 14:31 [Show Content]
txt file icon cmGlobalVisualStudio6Generator.h.patch.txt [^] (1,374 bytes) 2009-09-19 14:31 [Show Content]
txt file icon cmGlobalVisualStudio6Generator.h.patch.ansi.txt [^] (686 bytes) 2009-09-19 17:17 [Show Content]
txt file icon cmGlobalVisualStudio6Generator.cxx.patch.ansi.txt [^] (8,794 bytes) 2009-09-19 17:17 [Show Content]
zip file icon utilitytest.zip [^] (1,620 bytes) 2009-09-22 10:19

 Relationships
parent of 0008223closedBrad King Visual Studio 6 generator does not add targets to workspace in subdirs with EXCLUDE_FROM_ALL set 

  Notes
(0017619)
Shirokov Anatoly (reporter)
2009-09-19 04:03

I have tried to patch the Visual Studio 6 generator using the Visual Studio 7 generator approach. May be it helps to fix this issue:
http://www.cmake.org/pipermail/cmake/2009-September/032053.html [^]

BR,
Anatoly Shirokov.
(0017633)
Bill Hoffman (manager)
2009-09-19 08:43

Do you have a patch? If so attach it to this bug report.
(0017645)
Shirokov Anatoly (reporter)
2009-09-19 14:35

I've attached.
(0017646)
Shirokov Anatoly (reporter)
2009-09-19 15:10

I want to say that I'm not sure that this patch takes a care about all possible details. So please review changes and make needed corrections.
Thanks.
(0017649)
Bill Hoffman (manager)
2009-09-19 15:55

The patch seems to be in non-ascii. Can you convert to 8 bit ascii and re-attach?
(0017651)
Shirokov Anatoly (reporter)
2009-09-19 17:18

Done
(0017692)
Shirokov Anatoly (reporter)
2009-09-22 02:41

Additionally, I found that current implementation of void
cmGlobalGenerator::AddTargetDepends(cmTarget* target,
                                    cmGlobalGenerator::TargetDependSet&
                                    projectTargets)
does not include UTILITY projects to dependency set for the target.
My solution is
1) add virtual to cmGlobalGenerator::AddTargetDepends signature
2) override it in cmGlobalVisualStudio6Generator. Implementation looks like the following:
void cmGlobalVisualStudio6Generator::AddTargetDepends(cmTarget* target,
                                                      cmGlobalGenerator::TargetDependSet&
                                                      projectTargets)
{
    if( projectTargets.find(target) != projectTargets.end() )
        return;

    // add the target itself
    projectTargets.insert(target);
    // get the direct depends of target
    cmGlobalGenerator::TargetDependSet const& tset
        = this->GetTargetDirectDepends(*target);
    if(tset.size())
    {
        // if there are targets that depend on target
        // add them and their depends as well
        for(cmGlobalGenerator::TargetDependSet::const_iterator i =
            tset.begin(); i != tset.end(); ++i)
        {
            cmTarget* dtarget = *i;
            this->AddTargetDepends(dtarget, projectTargets);
        }
    }

    {
        std::set<cmStdString>::const_iterator i, end;
        i = target->GetUtilities().begin();
        end = target->GetUtilities().end();
        for(;i!= end; ++i)
        {
            cmTarget* dtarget = FindTarget(0, i->c_str());
            if( dtarget ) {
                std::string depName = this->GetUtilityForTarget(*dtarget, i->c_str());
                cmTarget* utarget = FindTarget(0, depName.c_str());
                if(utarget)
                    this->AddTargetDepends(utarget, projectTargets);
            }
        }
    }
}
(0017696)
Brad King (manager)
2009-09-22 09:43

The GetTargetDirectDepends method returns results computed by the cmComputeTargetDepends class. That class follows dependencies in the method:

  cmComputeTargetDepends::CollectTargetDepends

which clearly loops over both library and utility dependencies. Can you post an example project where this does not work?
(0017697)
Shirokov Anatoly (reporter)
2009-09-22 10:18

Ok, I've attached utilitytest.zip.

- unzip utilitytest.zip
- cd utilityzip
- mkdir build
- cd build
- cmake -G "Visual Studio 6" ..
- cd app
- start app.dsw

As you can see the app.dsw does not include libbase, libder and libbase_UTILITY, but app.dsp depends on libbase and libder.
(0017699)
Shirokov Anatoly (reporter)
2009-09-22 10:34

If you apply the attached *.ansi.txt patches, libbase and libder will appear in app.dsw, but libbase_UTILITY will be still missing.
If you implement AddTargetDepends as it mentioned above, libbase will appear in app.dsw as expected.
(0017700)
Brad King (manager)
2009-09-22 10:39

Okay, I see the difference. The "*_UTILITY" targets are different from what CMake calls "utility" targets internally. A normal utility target is the implementation of add_custom_target(). A "somelib_UTILITY" target is a fake custom target inserted as an implementation detail for this case:

  add_dependencies(my_exe my_library)

The goal is to make "my_exe" depend on "my_library", so that it builds afterwards, but NOT actually LINK to it. Unfortunately the VS IDE will link my_exe to my_library if the .dsw (or in VS 7 the .sln) lists a direct dependency between the targets even though my_exe.dsp does not mention my_library at all. Even worse, IIRC, in the case

  add_dependencies(my_static_lib_1 my_static_lib_2)

VS will list my_static_lib_2.lib on the librarian line for my_static_lib_1 and *copy* all of the objects, again even though my_static_lib_1.dsp file does not specify my_static_lib_2...just the .dsw reference is enough!

The work-around we use is to replace the direct dependency on a library "somelib" with a dependency on an intermediate "somelib_UTILITY" target which then depends on "somelib". CMake's VS generators do this using a last-second replacement of the real direct dependency with the intermediate target just as they write the .dsw or .sln files. We want to avoid every including the _UTILITY targets in analysis of build rules before generation.

You're see a ..._UTILTITY target because of the line

  add_dependencies( app lib )

in your example. It makes 'lib' a non-link dependency of 'app'. This is unnecessary. Just the line

  target_link_libraries( app lib )

already adds the dependency. The add_dependencies call is only necessary if you want the dependency *without* linking.

Although the line is not necessary in your example, it might be in a real project that wants such a dependency. This is potentially an existing bug that affects VS generators for all versions. I think your fix is correct but it can be simpler, and should be done for all generators. I'll investigate further.
(0017701)
Shirokov Anatoly (reporter)
2009-09-22 10:39

Sorry, the last sentence must be changed on
If you implement AddTargetDepends as it mentioned above, libbase_UTILITY will appear in app.dsw as expected.
(0017855)
Brad King (manager)
2009-09-30 16:07
edited on: 2009-09-30 16:08

I've combined changes from patch

  cmGlobalVisualStudio6Generator.(h|cxx).patch.ansi.txt

with those from the patch in issue 0008223. Both patches actually address both bugs because they both use the VS 7 generator's approach to computing the set of targets in a solution.

The following commits represent the combined patches plus some more cleanup:

Move OrderedTargetDependSet into VS superclass
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio7Generator.cxx,v <-- Source/cmGlobalVisualStudio7Generator.cxx
new revision: 1.110; previous revision: 1.109
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio7Generator.h,v <-- Source/cmGlobalVisualStudio7Generator.h
new revision: 1.53; previous revision: 1.52
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudioGenerator.cxx,v <-- Source/cmGlobalVisualStudioGenerator.cxx
new revision: 1.19; previous revision: 1.18
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudioGenerator.h,v <-- Source/cmGlobalVisualStudioGenerator.h
new revision: 1.13; previous revision: 1.12

Use target dependency closure for VS 6 solutions
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio6Generator.cxx,v <-- Source/cmGlobalVisualStudio6Generator.cxx
new revision: 1.80; previous revision: 1.79

Remove unused members of local VS 6 generator
/cvsroot/CMake/CMake/Source/cmLocalVisualStudio6Generator.cxx,v <-- Source/cmLocalVisualStudio6Generator.cxx
new revision: 1.161; previous revision: 1.160
/cvsroot/CMake/CMake/Source/cmLocalVisualStudio6Generator.h,v <-- Source/cmLocalVisualStudio6Generator.h
new revision: 1.26; previous revision: 1.25

(0017863)
Brad King (manager)
2009-10-01 10:27

I've committed additional changes to address the **_UTILITY target problem from comments #c17692 and #c17700.

Cleanup cmGlobalGenerator::GetTargetSets method
/cvsroot/CMake/CMake/Source/cmGlobalGenerator.cxx,v <-- Source/cmGlobalGenerator.cxx
new revision: 1.260; previous revision: 1.259
/cvsroot/CMake/CMake/Source/cmGlobalGenerator.h,v <-- Source/cmGlobalGenerator.h
new revision: 1.127; previous revision: 1.126
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio6Generator.cxx,v <-- Source/cmGlobalVisualStudio6Generator.cxx
new revision: 1.81; previous revision: 1.80
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio71Generator.cxx,v <-- Source/cmGlobalVisualStudio71Generator.cxx
new revision: 1.56; previous revision: 1.55
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudio7Generator.cxx,v <-- Source/cmGlobalVisualStudio7Generator.cxx
new revision: 1.111; previous revision: 1.110

Add alternative _UTILITY targets to all solutions
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudioGenerator.cxx,v <-- Source/cmGlobalVisualStudioGenerator.cxx
new revision: 1.20; previous revision: 1.19
/cvsroot/CMake/CMake/Source/cmGlobalVisualStudioGenerator.h,v <-- Source/cmGlobalVisualStudioGenerator.h
new revision: 1.14; previous revision: 1.13

 Issue History
Date Modified Username Field Change
2009-09-19 00:57 Shirokov Anatoly New Issue
2009-09-19 04:03 Shirokov Anatoly Note Added: 0017619
2009-09-19 08:43 Bill Hoffman Note Added: 0017633
2009-09-19 08:44 Bill Hoffman Status new => assigned
2009-09-19 08:44 Bill Hoffman Assigned To => Bill Hoffman
2009-09-19 14:31 Shirokov Anatoly File Added: cmGlobalVisualStudio6Generator.cxx.patch.txt
2009-09-19 14:31 Shirokov Anatoly File Added: cmGlobalVisualStudio6Generator.h.patch.txt
2009-09-19 14:35 Shirokov Anatoly Note Added: 0017645
2009-09-19 15:10 Shirokov Anatoly Note Added: 0017646
2009-09-19 15:55 Bill Hoffman Note Added: 0017649
2009-09-19 17:17 Shirokov Anatoly File Added: cmGlobalVisualStudio6Generator.h.patch.ansi.txt
2009-09-19 17:17 Shirokov Anatoly File Added: cmGlobalVisualStudio6Generator.cxx.patch.ansi.txt
2009-09-19 17:18 Shirokov Anatoly Note Added: 0017651
2009-09-22 02:41 Shirokov Anatoly Note Added: 0017692
2009-09-22 09:43 Brad King Note Added: 0017696
2009-09-22 10:18 Shirokov Anatoly Note Added: 0017697
2009-09-22 10:19 Shirokov Anatoly File Added: utilitytest.zip
2009-09-22 10:34 Shirokov Anatoly Note Added: 0017699
2009-09-22 10:39 Brad King Note Added: 0017700
2009-09-22 10:39 Shirokov Anatoly Note Added: 0017701
2009-09-30 15:21 Brad King Relationship added parent of 0008223
2009-09-30 16:07 Brad King Note Added: 0017855
2009-09-30 16:08 Brad King Assigned To Bill Hoffman => Brad King
2009-09-30 16:08 Brad King Note Edited: 0017855
2009-10-01 10:27 Brad King Note Added: 0017863
2009-10-01 10:30 Brad King Status assigned => closed
2009-10-01 10:30 Brad King Resolution open => fixed


Copyright © 2000 - 2018 MantisBT Team