View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008562CMakeCMakepublic2009-02-19 10:232009-04-06 09:39
ReporterThomas Harning 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008562: VS 2003 - CMake's project dependencies create unnecessary library links
DescriptionIn Visual Studio 2003, CMake adds both a project dependency and library reference in EXE generation.
This causes VS's command-line to have both CMake's version of the library reference _AND_ VS's idea of the library reference.

This is odd, since VS has a special 'Reference' category for library linking, but it works in many cases.

The case where it does not work is when CMake figures out a dependency (ex: custom-command based dependency) and adds a project dependency. This project dependency is required for ordering... however if that dependency happens to be a library, VS will link it in.
Tagsstudio, visual
Attached Files

 Relationships

  Notes
(0015328)
Brad King (manager)
2009-02-24 10:52

This "project-dependency ==> link" feature of VS is extremely annoying. I've gone through great pains to work around it already. Try this project:

  cmake_minimum_required(VERSION 2.6)
  project(FOO C)
  add_library(foo foo.c)
  add_executable(bar bar.c)
  add_dependencies(bar foo)

When you load it in VS you'll see a "foo_UTILITY" target that serves as an intermediate dependency between bar and foo to prevent bar from linking foo.

Is this not working for you? Can you post a project that illustrates your problem?
(0015329)
Brad King (manager)
2009-02-24 11:02
edited on: 2009-02-24 11:02

BTW, the reason we explicitly list the libraries to link in Linker/Input/AdditionalDependencies is because there is no other way to enforce the order among many libraries when some are projects in the solution and others are not.

Ideally, I want to tell VS to never add any link entries itself, but I cannot seem to get this to happen in any version earlier than 2005.

(0015915)
Thomas Harning (reporter)
2009-04-04 14:35

Hmm... a similar project for 2003 didn't seem to generate a 'foo_UTILITY'.

Though it was through a build target dependency rather than that sort of dependency. I think it was using 2.6.2 (2.6.3 recently came out)

If you know that executable => custom action-based source-file => library was fixed in this release... let me know.

If you are not 100% sure... I'll give 2003 a try when I again get access to the machine with it available...

Turns out we had to jump ship from 2003 to 2008 since we had to start supporting 64-bit...
(0015916)
Thomas Harning (reporter)
2009-04-04 15:18

It would appear that even in 2.6.2 the solution works.

Example that creates unwanted link:
  cmake_minimum_required(VERSION 2.6)
  project(FOO C)
  add_library(foo foo.c)
  add_custom_command(
    OUTPUT foo2.c
    COMMAND echo \#define x > foo2.c
    DEPENDS foo
  )
  add_executable(bar bar.c foo2.c)


If you do the 'add_dependencies(bar foo) then the utility target is created... bizarre setup that VS2003 honors dependency ordering even when 'disabled' targets are there... then again, build errors don't stop the rest of the project building (even in 2008...)

I'd say the issue is resolved... though perhaps a note somewhere ~ the 2003 generator could help...

 Issue History
Date Modified Username Field Change
2009-02-19 10:23 Thomas Harning New Issue
2009-02-19 10:23 Thomas Harning Tag Attached: studio
2009-02-19 10:23 Thomas Harning Tag Attached: visual
2009-02-24 10:11 Bill Hoffman Status new => assigned
2009-02-24 10:11 Bill Hoffman Assigned To => Brad King
2009-02-24 10:52 Brad King Note Added: 0015328
2009-02-24 11:02 Brad King Note Added: 0015329
2009-02-24 11:02 Brad King Note Edited: 0015329
2009-04-04 14:35 Thomas Harning Note Added: 0015915
2009-04-04 15:18 Thomas Harning Note Added: 0015916
2009-04-06 09:39 Brad King Status assigned => closed
2009-04-06 09:39 Brad King Resolution open => fixed


Copyright © 2000 - 2018 MantisBT Team