I haven't gotten a response yet, I guess you guys stay pretty busy :) Am I correct to assume that add_custom_command() still needs a CONFIG option to support varying numbers & names of output files per configuration, based on my previous description of the problem I'm facing?
On Wed, May 22, 2013 at 5:49 PM, Robert Dailey <[email protected]> wrote: > On Mon, May 13, 2013 at 1:30 PM, Brad King <[email protected]> wrote: >> On 05/13/2013 02:07 PM, Robert Dailey wrote: >>> Actually now that I think about this a littler closer, changing the >>> generator expressions may not work for a specific case I'm blocked on. >>> >>> I store my third party library binaries in a "debug" and "release" >>> directories. I have a custom target that I define to copy the >>> appropriate debug or release DLLs to the appropriate output >>> directories, so that when I debug my applications, they find the >>> appropriate DLLs in the same directory. So the copy mapping should be >>> as follows: >>> >>> debug -> Debug >>> release -> Release >>> release -> RelWithDebInfo >>> release -> MinSizeRel >>> >>> Specifically for the RELEASE case. I can't use $<CONFIGURATION> for >>> the source directory, since the name is "release" between all 3 >>> release configurations. This case is easily solved with issue 9974, >>> however. Any thoughts? >> >> This looks like the common use case I explain here: >> >> http://www.cmake.org/Bug/view.php?id=9974#c29033 >> >> You don't need any new features for it. > > (Sorry for the double-email Brad, I forgot to include the mailing list > in my reply) > > I wanted to follow up here with some concerns. Right now I cannot > create an imported target with multiple output files. Suppose I have a > library with the following DLLs: > > library1: > debug: > a_d.dll > b_d.dll > c_d.dll > release: > a.dll > c.dll > > Note that there is no corresponding "b.dll" in release, so I need to > handle a couple of cases: > 1. A library may have a different number of DLLs between release & > debug configurations > 2. The library names between configurations need not match (as shown > by the _d suffix). > > I don't think the imported target solution will work here. Can you > think of any other clever workarounds, or do we need a different > feature in CMake for this? Basically I'm creating a custom target that > depends on these output files. I have 1 custom command per > configuration to copy these files to the configuration output > directory, but since I cannot specify DEPENDS_<CONFIG> in > add_custom_target(), I'm not able to specify varying numbers of > dependencies. Could we perhaps add a DEPENDS_<CONFIG> to > add_custom_target, so that each configuration will end up depending on > different custom commands? > > Thanks in advance. -- 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
