On 12/14/2011 11:23 AM, Alexander Broekhuis wrote:
> Hi,
> 
>>
>>
>> First of all, you definitely need the library target in order to build
>> the library, and CMake ignores each file in the list of sources which
>> is not necessary for this purpose. IMO, that's quite reasonable; e.g.,
>> you wouldn't want to have the library relinked or even completely re-
>> built because the manifest has been touched. Actually, there's simply
>> no dependency of the library on the manifest.
> 
> 
> This makes sense, the dependency is the other way, from the bundle to the
> library. Until now I tried to see the manifest file as part of the target,
> but I could as well see it a separate step.

Yes, the dependencies in your case are, if I'm not mistaken,

         +--> library
         |
bundle --+
         |
         +--> manifest

with "-->" meaning "depends on". With your original approach, you tried
to express them as "bundle --> library --> manifest", and that's not
appropriate as it does not reflect the actual relationships.

>> Furthermore, a TARGET-
>> style custom command is triggered only when its target is rebuilt, so
>> generating the ZIP file in this way is unsuitable since you will miss
>> its dependency on the manifest. Thus, to express this dependency, you
>> need to have an own target for the ZIP file, so you will end up with
>> two targets if you want to have the dependencies set up correctly,
>> although you'd prefer to have just one. BTW, is this really bad?
>>
> 
> Reading the replies I think this might be the best solution. In this case I
> would like to be able to add dependencies to the top-level target, eg I
> would like to add my "bundle" targets to "ALL" since building the project
> implicitly means the bundles need to be generated.

This sounds perfectly reasonable, IMO.

> Again, previously I tried to see the Manifest file as a part of the
> compilation unit. So a change to the file would trigger a rebuild of the
> library and zip file, instead of only the zip file.

In this regard, the question is: Is the manifest actually necessary to
build the library, i.e. must the latter be recompiled and/or relinked
when the former changes? AFAICS, that's not the case, so the manifest
should not be considered as one of the library's prerequisites.

Regards,

Michael

>>>>> 2011/12/13 Michael Hertling <mhertl...@online.de>
>>>>>
>>>>>> On 12/12/2011 11:40 AM, Alexander Broekhuis wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Can anyone help me with this? I haven't found a proper solution
>> myself
>>>>>> yet..
>>>>>>
>>>>>> Does the following examplary project do what you intend?
>>>>>>
>>>>>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
>>>>>> PROJECT(P C)
>>>>>> SET(CMAKE_VERBOSE_MAKEFILE ON)
>>>>>> # The library target:
>>>>>> FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
>>>>>> ADD_LIBRARY(f SHARED f.c)
>>>>>> # The README file:
>>>>>> FILE(WRITE ${CMAKE_BINARY_DIR}/README "Very important information!\n")
>>>>>> # The ZIP file command:
>>>>>> ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/f.zip
>>>>>>    COMMAND zip -j ${CMAKE_BINARY_DIR}/f.zip
>>>>>>                   ${CMAKE_BINARY_DIR}/README
>>>>>>                   $<TARGET_FILE:f>
>>>>>>    DEPENDS ${CMAKE_BINARY_DIR}/README)
>>>>>> # The ZIP file target:
>>>>>> ADD_CUSTOM_TARGET(zip ALL DEPENDS ${CMAKE_BINARY_DIR}/f.zip)
>>>>>> # Trigger ZIP file target after library target:
>>>>>> ADD_CUSTOM_COMMAND(TARGET f POST_BUILD
>>>>>>    COMMAND ${CMAKE_COMMAND} -E remove ${CMAKE_BINARY_DIR}/f.zip
>>>>>>    COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
>>>>>>                             --config $<CONFIGURATION>
>>>>>>                             --target zip)
>>>>>>
>>>>>> The basic idea is the decomposition of the ZIP file's generation into
>> a
>>>>>> custom target, an OUTPUT-style custom command and a TARGET-style
>> custom
>>>>>> command, the latter in conjunction with CMake's --build switch.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>> 2011/12/8 Alexander Broekhuis <a.broekh...@gmail.com>
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> In my project, some top level targets depend on simple text files.
>>>> These
>>>>>>>> targets produce a zip file as output, this is done using a custom
>>>>>> command
>>>>>>>> with a post-build to a library target.
>>>>>>>> Part of the zip file are some simple text files, which are included
>>>>>> using
>>>>>>>> some custom CPack handling inside the custom command.
>>>>>>>>
>>>>>>>> How can I let the top level target depend on these text files as
>> well?
>>>>>> In
>>>>>>>> other words, if a text files changes, the zip file has to be
>>>>>> regenerated.
>>>>>>>> These text files are not generated or copied etc. So a simple
>> DEPENDS
>>>>>> would
>>>>>>>> suffice. I know add_custom_command(OUTPUT has support for this, but
>> am
>>>>>>>> wondering how to do this with add_custom_command(TARGET.
>>>>>>>>
>>>>>>>> TiA!
>>>>>>>>
>>>>>>>> --
>>>>>>>> Met vriendelijke groet,
>>>>>>>>
>>>>>>>> Alexander Broekhuis
--

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://www.cmake.org/mailman/listinfo/cmake

Reply via email to