On Fri, Sep 13, 2013 at 8:21 AM, Brad King <brad.k...@kitware.com> wrote:
> On 09/12/2013 05:36 PM, James Bigler wrote: > > I discovered a long time ago that VS would link the output of a custom > command. > > I just ran local experiments with VS 6, 7.1, 8, and 9 by manually modifying > the ExternalOBJ test project in the IDE and building. Results: > > - MAIN_DEPENDENCY has no effect on whether custom command outputs are > linked. It does not matter where the command is attached. > > - VS 6 and 7.1 do link custom command outputs named .obj, and also > *avoid duplicating* them if the .obj files are listed explicitly too. > > - VS 8 and 9 do not link custom command outputs, even named .obj. I get > unresolved symbols unless I add the .obj files explicitly. > > What changed in VS 10 is that they still link custom command outputs > but also link .obj files explicitly listed *without de-duplication*. > > CMake works around this with some fairly complicated logic that detects > for each EXTERNAL_OBJECT file explicitly listed whether it is also the > output of a custom command in the current target. If so, it lists the > object as <None> to avoid duplicate linking. If not, it uses <Object> > to link it since it wouldn't be linked otherwise. This is very tricky > when the same object appears in multiple targets and one of them has it > in a custom command output and others do not. > > In order to avoid this complicated, possibly error-prone logic for > VS >= 11, CMake takes advantage of the LinkObjects setting to get the > behavior of VS 8 and 9. Then it can always list all EXTERNAL_OBJECT > files with <Object>. > > > I didn't need to add the obj file to the project anymore. > > The general intention in the CMake interface is that custom command > outputs are only used in targets that list the outputs as sources. > This goes for object files too. We intend only to link external > objects that are explicitly listed as sources of the target, whether > they are custom command outputs or not. This is the case with all > non-VS generators, and with VS 8, 9, and now 11. It is not possible > to implement on VS 6, 7.1, and 10, but we approximate it by setting > things up to tolerate the duplication. > > The solution here is to always list the .obj file in the target. This > is what the ExternalOBJ test covers and is known to work. Depending > on the VS-(version-)specific behavior for linking custom command > outputs is asking for trouble IMO. > > OK, but I *know* this worked for VS 8, 9 and 10 (11 too with CMake 2.8.10) with previous versions of CMake, so I'm not sure how your test differs from FindCUDA. > > This was great for VS versions that didn't have source groupings. > > Every version of VS supported by CMake has source groups, and the > CMake generators put all objects in a dedicated group by default. > > Oh, perhaps this was a new feature for CMake. My memory of the changes over the last 5 years is kind of sketchy. ;) > > I think this could work a little better if you allowed linking of the > > output of a custom command if MAIN_DEPENDENCY is set and the output of > > that command is only OBJ files or files that have the EXTERNAL_OBJECT > > property set to true. > > As reported above that can't be implemented with VS 8 and 9 directly. > Also it is contrary to the only-use-sources-listed intention described > above. > > > I should also point out that whatever solution comes into being, it > > should get integrated into 2.8.12 since this affects FindCUDA.cmake. > > IMO the solution should be the attached patch. I'm not set up to > test it, so please try it out. > > So it seems like I was using an undocumented feature that got broken (probably for good reason) and there's a patch that makes it work again. Yeah, this is fine. I tried it on VS 9, 10, and 11. James
-- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
