Re: [CMake] Top level target depending on a file
Hi,
CMake takes great care regarding dependencies on files which are needed
to build targets, i.e. usually, it's not necessary to specify any extra
dependencies of a target on a file. In my exemplary project, the README
file is actually not needed to build the library target, so CMake does
not add an appropriate dependency. However, the README file is needed
to generate the ZIP file, so the latter must be a separate target with
dependencies on its own, whereas the approach to generate the ZIP file
by a TARGET-style custom command for the library target is wrong, IMO;
one can just trigger the ZIP file target in this way. In other words:
You have two targets with different dependencies - don't mix them up.
In my case the output is the ZIP file. So the zip file is produced by the
top level target, and I don't want/need a separate target for it.
The generated zip file (bundle) is the deployable unit which contains a
library and additional information needed (at runtime) to use the library,
which is located in the manifest file. If the manifest file changes,
without a change to the library source, the zip file still needs to be
regenerated. As such the output of the target depends on the manifest file,
hence the need for a dependency to a file.
PS: Please don't drop the ML.
I am used to mailing lists having the reply-to set, will try to keep it in
mind.
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
--
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
Re: [CMake] Top level target depending on a file
2011/12/14 Alexander Broekhuis a.broekh...@gmail.com:
Hi,
CMake takes great care regarding dependencies on files which are needed
to build targets, i.e. usually, it's not necessary to specify any extra
dependencies of a target on a file. In my exemplary project, the README
file is actually not needed to build the library target, so CMake does
not add an appropriate dependency. However, the README file is needed
to generate the ZIP file, so the latter must be a separate target with
dependencies on its own, whereas the approach to generate the ZIP file
by a TARGET-style custom command for the library target is wrong, IMO;
one can just trigger the ZIP file target in this way. In other words:
You have two targets with different dependencies - don't mix them up.
In my case the output is the ZIP file. So the zip file is produced by the
top level target, and I don't want/need a separate target for it.
Yes but CMake's jobs is to build libraries and executables not bundle
which is more the CPack's job, however I understand your point.
An extra target may be a small price to pay, no?
The generated zip file (bundle) is the deployable unit which contains a
library and additional information needed (at runtime) to use the library,
which is located in the manifest file. If the manifest file changes, without
a change to the library source, the zip file still needs to be regenerated.
As such the output of the target depends on the manifest file, hence the
need for a dependency to a file.
Yes sure, sometimes file dependencies are needed.
By the way I see you custom-commands in order to create a bundle on MacOS?
Did you try try CPack MacOSX bundle generator?
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29
May be that's already what your
CPackConfig-${BUNDLE_NAME}-bundle.cmake contains?
Or may be you had to work-around some generator's bug?
The broader question; why didn't you use one of the MacOSX CPack generator:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DragNDrop_.28OSX_only.29
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#PackageMaker_.28OSX_only.29
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#OSXX11_.28OSX_only.29
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29
I'm not a MacOS user but I may have to use some soon enough so I'm curious.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
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
Re: [CMake] Top level target depending on a file
Hi, Thanks for you replies, In my case the output is the ZIP file. So the zip file is produced by the top level target, and I don't want/need a separate target for it. Yes but CMake's jobs is to build libraries and executables not bundle which is more the CPack's job, however I understand your point. An extra target may be a small price to pay, no? Well I'd rather have a solution without CPack, CPack being a package creator, whereas my bundle is a development item. If all fails I could make the extra target, but again, the zip file in my case is equivalent to a library. Yes sure, sometimes file dependencies are needed. By the way I see you custom-commands in order to create a bundle on MacOS? Did you try try CPack MacOSX bundle generator? http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29 My bundles don't have anything to do with MacOS bundles, the name is a coincidence. Some background might be helpful now.. I am using CMake to build Apache Celix, which is a project in the Apache Incubator. Apache Celix is an implementation of the OSGi specification in C. I am not sure if you are familiar with OSGi, but it provides a modular system for Java in which new functionality can be added/removed/updated at runtime. In Java OSGi a bundle is a regular Jar file with additional information in the Manifest file. For Celix we use a similar solution (since a jar file is actually a zip file..) where the library is packed in a zip file together with the manifest file. One bundle contains always one library, this is why I see the Celix bundles as top level artifacts, and not the library. As such, from the Celix point of view it makes sense to have one target for creating a Bundle. More information can be found at: http://incubator.apache.org/celix/ And specifically on the build files: http://incubator.apache.org/celix/documentation/buildingandrunning.html I hope this makes all a little bit clearer, I understand I am using a rather specific solution, but the flexibility of CMake has really helped my achieving what I wanted (until now?). This way fits the modular development needed in an OSGi based environment. -- 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
Re: [CMake] Top level target depending on a file
On 12/14/2011 09:30 AM, Alexander Broekhuis wrote:
Hi,
CMake takes great care regarding dependencies on files which are needed
to build targets, i.e. usually, it's not necessary to specify any extra
dependencies of a target on a file. In my exemplary project, the README
file is actually not needed to build the library target, so CMake does
not add an appropriate dependency. However, the README file is needed
to generate the ZIP file, so the latter must be a separate target with
dependencies on its own, whereas the approach to generate the ZIP file
by a TARGET-style custom command for the library target is wrong, IMO;
one can just trigger the ZIP file target in this way. In other words:
You have two targets with different dependencies - don't mix them up.
In my case the output is the ZIP file. So the zip file is produced by the
top level target, and I don't want/need a separate target for it.
The generated zip file (bundle) is the deployable unit which contains a
library and additional information needed (at runtime) to use the library,
which is located in the manifest file. If the manifest file changes,
without a change to the library source, the zip file still needs to be
regenerated. As such the output of the target depends on the manifest file,
hence the need for a dependency to a file.
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. 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?
Regards,
Michael
PS: Please don't drop the ML.
I am used to mailing lists having the reply-to set, will try to keep it in
mind.
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
Re: [CMake] Top level target depending on a file
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.
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.
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.
Regards,
Michael
PS: Please don't drop the ML.
I am used to mailing lists having the reply-to set, will try to keep it
in
mind.
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
--
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
Re: [CMake] Top level target depending on a file
2011/12/14 Alexander Broekhuis a.broekh...@gmail.com: Hi, Thanks for you replies, Yes but CMake's jobs is to build libraries and executables not bundle which is more the CPack's job, however I understand your point. An extra target may be a small price to pay, no? Well I'd rather have a solution without CPack, CPack being a package creator, whereas my bundle is a development item. If all fails I could make the extra target, but again, the zip file in my case is equivalent to a library. I get that. Yes sure, sometimes file dependencies are needed. By the way I see you custom-commands in order to create a bundle on MacOS? Did you try try CPack MacOSX bundle generator? http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29 My bundles don't have anything to do with MacOS bundles, the name is a coincidence. Some background might be helpful now.. Ok. May be OSGi_BUNDLE would be a better name then :-] I am using CMake to build Apache Celix, which is a project in the Apache Incubator. Apache Celix is an implementation of the OSGi specification in C. I am not sure if you are familiar with OSGi, but it provides a modular system for Java in which new functionality can be added/removed/updated at runtime. In Java OSGi a bundle is a regular Jar file with additional information in the Manifest file. I did cross some OSGi in Java not so long ago. For Celix we use a similar solution (since a jar file is actually a zip file..) where the library is packed in a zip file together with the manifest file. One bundle contains always one library, this is why I see the Celix bundles as top level artifacts, and not the library. As such, from the Celix point of view it makes sense to have one target for creating a Bundle. More information can be found at: http://incubator.apache.org/celix/ And specifically on the build files: http://incubator.apache.org/celix/documentation/buildingandrunning.html I hope this makes all a little bit clearer, I understand I am using a rather specific solution, but the flexibility of CMake has really helped my achieving what I wanted (until now?). This way fits the modular development needed in an OSGi based environment. Yes now it's clear. You are looking for something like add_library like command which would produce the OSGi bundle which is the purpose of your bundle macro. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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
Re: [CMake] Top level target depending on a file
On 12/14/2011 10:55 AM, Alexander Broekhuis wrote: Hi, Thanks for you replies, In my case the output is the ZIP file. So the zip file is produced by the top level target, and I don't want/need a separate target for it. Yes but CMake's jobs is to build libraries and executables not bundle which is more the CPack's job, however I understand your point. An extra target may be a small price to pay, no? Well I'd rather have a solution without CPack, CPack being a package creator, whereas my bundle is a development item. If all fails I could make the extra target, but again, the zip file in my case is equivalent to a library. Not technically, because the ZIP file has different dependencies than the library, and these dependencies can't be expressed for the latter. However, if you (1) absolutely want to generate the ZIP file by a TARGET-style custom command attached to the library target, (2) get along with Makefiles and (3) are willing to pay an extra charge, you might use the LINK_DEPENDS target property for your purposes. If set on the library target and specifying the manifest file, it will have the library relinked and, thus, the ZIP file command triggered when the manifest is newer than the library. Of course, this means to accept actually unnecessary link operations which can be quite expensive. Regards, Michael Yes sure, sometimes file dependencies are needed. By the way I see you custom-commands in order to create a bundle on MacOS? Did you try try CPack MacOSX bundle generator? http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29 My bundles don't have anything to do with MacOS bundles, the name is a coincidence. Some background might be helpful now.. I am using CMake to build Apache Celix, which is a project in the Apache Incubator. Apache Celix is an implementation of the OSGi specification in C. I am not sure if you are familiar with OSGi, but it provides a modular system for Java in which new functionality can be added/removed/updated at runtime. In Java OSGi a bundle is a regular Jar file with additional information in the Manifest file. For Celix we use a similar solution (since a jar file is actually a zip file..) where the library is packed in a zip file together with the manifest file. One bundle contains always one library, this is why I see the Celix bundles as top level artifacts, and not the library. As such, from the Celix point of view it makes sense to have one target for creating a Bundle. More information can be found at: http://incubator.apache.org/celix/ And specifically on the build files: http://incubator.apache.org/celix/documentation/buildingandrunning.html I hope this makes all a little bit clearer, I understand I am using a rather specific solution, but the flexibility of CMake has really helped my achieving what I wanted (until now?). This way fits the modular development needed in an OSGi based environment. -- 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
Re: [CMake] Top level target depending on a file
Yes now it's clear. You are looking for something like add_library like command which would produce the OSGi bundle which is the purpose of your bundle macro. Yes this is exactly what I'd like to do, but taking Michael remarks into account, I now think it would make more sense to have the dependency the other way around, So the single add_bundle macro could still add all the required targets, but I will probably end up with 2 targets, one for the library, and one for the zip file. This way the library doesn't need to be rebuild if the manifest file changes. And since the zip target depends on the library target the dependencies are correctly set up. Unless someone has another idea, I am open to any solution/proposal :). -- 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
Re: [CMake] Top level target depending on a file
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
Re: [CMake] Top level target depending on a file
Hi,
The only issue would be that you have to call (i.e. build) the new
custom target explicitely instead of relying on POST BUILD.
I had hoped it would be as simple as adding a DEPENDS to the custom target,
or something similar.
Note that may be I didn't catch your usage so may be you can
send us the concerned bits of your CMakeLists.txt
What I have is a macro which takes care of adding a library, this library
is wrapped in a zip file using CPack. Together with the library there is a
manifest file which needs to be added to the zip file.
I would like to be able to track changes to this manifest file and trigger
an out-of-date so that the zip is is recreated when building again.
The macro I use:
===
MACRO(bundle)
PARSE_ARGUMENTS(BUNDLE SOURCES;FILES;DIRECTORIES ${ARGN})
LIST(GET BUNDLE_DEFAULT_ARGS 0 BUNDLE_NAME)
add_library(${BUNDLE_NAME} SHARED ${BUNDLE_SOURCES})
install (DIRECTORY META-INF DESTINATION . COMPONENT ${BUNDLE_NAME})
install (TARGETS ${BUNDLE_NAME} DESTINATION . COMPONENT ${BUNDLE_NAME})
if (BUNDLE_FILES)
install (FILES ${BUNDLE_FILES} DESTINATION . COMPONENT
${BUNDLE_NAME})
endif(BUNDLE_FILES)
if (BUNDLE_DIRECTORIES)
install (DIRECTORY ${BUNDLE_DIRECTORIES} DESTINATION . COMPONENT
${BUNDLE_NAME})
endif(BUNDLE_DIRECTORIES)
SET(__bundleConfig
${CMAKE_CURRENT_BINARY_DIR}/CPackConfig-${BUNDLE_NAME}-bundle.cmake)
SET(BUNDLE_BIN_DIR ${CMAKE_CURRENT_BINARY_DIR})
CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/cmake/CPackConfig.in
${__bundleConfig} @ONLY)
ADD_CUSTOM_COMMAND(TARGET ${BUNDLE_NAME}
POST_BUILD
COMMAND ${CPACK_COMMAND} ARGS --config ${__bundleConfig}
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/bundles
)
SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
${PROJECT_BINARY_DIR}/bundles/${BUNDLE_NAME}.zip)
ENDMACRO(bundle)
--
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
Re: [CMake] Top level target depending on a file
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
Re: [CMake] Top level target depending on a file
On 12/13/2011 03:24 PM, Alexander Broekhuis wrote:
Hi,
Thanks for the hint, I haven't tried it yet, but looks good at the first
glance!
I'll try this.
Is this worth a feature request? To be able to add a file as a dependency
to a target would make sense to me.. The posted issue (
http://public.kitware.com/Bug/view.php?id=8438) talks about target
dependencies, not as much about file dependenies.
CMake takes great care regarding dependencies on files which are needed
to build targets, i.e. usually, it's not necessary to specify any extra
dependencies of a target on a file. In my exemplary project, the README
file is actually not needed to build the library target, so CMake does
not add an appropriate dependency. However, the README file is needed
to generate the ZIP file, so the latter must be a separate target with
dependencies on its own, whereas the approach to generate the ZIP file
by a TARGET-style custom command for the library target is wrong, IMO;
one can just trigger the ZIP file target in this way. In other words:
You have two targets with different dependencies - don't mix them up.
What might be really worth a feature request are generator expressions
in the DEPENDS clause of custom commands/targets. If we're able to say
DEPENDS ${CMAKE_BINARY_DIR}/README) $TARGET_FILE:f
in the ZIP file's custom command, it wouldn't be necessary to remove
the ZIP file prior to triggering its target after the library has
been (re)built. This could also be slightly more efficient.
Regards,
Michael
PS: Please don't drop the ML.
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
Re: [CMake] Top level target depending on a file
Hi, Can anyone help me with this? I haven't found a proper solution myself yet.. 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 -- 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
Re: [CMake] Top level target depending on a file
2011/12/12 Alexander Broekhuis a.broekh...@gmail.com: Hi, Can anyone help me with this? I haven't found a proper solution myself yet.. The fact is there is no builtin support for what you ask see: http://public.kitware.com/Bug/view.php?id=8438 But the thing is. Why don't you create a top level target using add_custom_target instead of a post-build event? this custom target would depend on both the text file and the library target your are building. The only issue would be that you have to call (i.e. build) the new custom target explicitely instead of relying on POST BUILD. Note that may be I didn't catch your usage so may be you can send us the concerned bits of your CMakeLists.txt -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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
[CMake] Top level target depending on a file
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
